RE: [PATCH v1 3/3] scsi: ufs: Make UPIU trace easier differentiate among CDB, OSF, and TM

[Avri Altman <Avri.Altman@wdc.com>]

> 
> On Mon, 7 Dec 2020 16:40:51 +0000
> Avri Altman <Avri.Altman@wdc.com> wrote:
> 
> > >
> > > On Mon, 7 Dec 2020 07:57:27 +0000
> > > Avri Altman <Avri.Altman@wdc.com> wrote:
> > >
> > > > >
> > > > >         TP_printk(
> > > > > -               "%s: %s: HDR:%s, CDB:%s",
> > > > > +               "%s: %s: HDR:%s, %s:%s",
> > > > >                 __get_str(str), __get_str(dev_name),
> > > > >                 __print_hex(__entry->hdr, sizeof(__entry->hdr)),
> > > > > +               __get_str(tsf_type),
> > > > This breaks what current parsers expects.
> > > > Why str is not enough to distinguish between the command?
> > >
> > > Hopefully it shouldn't. Reading from user space should use the
> > > libtraceevent library, that reads the format files and extracts the raw
> > > data to find the fields. As long as the field exists, it should not break
> > > user space parsers. If it does, please let me know, and I'll gladly help
> > > change the user space code to use libtraceevent :-)
> > Hi Steve,
> > Thanks. I wasn't aware of libtraceevent - is this a new thing?
> 
> Actually, it's been around almost as long as ftrace. But unfortunately,
> it's just now becoming a separate library. It was originally developed for
> trace-cmd, but has been copied into perf, power-top and rasdaemon. But
> this
> copying is inefficient and a maintenance nightmare, and we finally have the
> library as a stand alone, and hopefully will be delivered by distributions
> (I believe they are packaging it).
> 
>    https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/
> 
> Looks like distros are starting to catch on.
> 
>   https://packages.debian.org/unstable/libtraceevent-dev
> 
> 
> We are currently working on libtracefs
> 
>   https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/
> 
> Which will make it a lot easier for applications to interact with the
> tracefs file system. I'm hoping to have this ready for distros by the end
> of the year. We have applications coming that depend on these.
> 
> >
> > We have a relatively sophisticated analysis platform that utilizes raw traces,
> > Among which the upiu trace is the most important and informative.
> >
> > This tool has evolved over the years, adding more and more parsers per
> need,
> > and the users are picking the appropriate parser per the trace they used.
> >
> > We will surely be glad to adopt new tracing capabilities,
> 
> I think libtraceevent and libtracefs would be a much welcome addition for
> upiu trace as it would be reading raw data (very fast), and have an API
> that makes doing so much simpler. For example, I just wrote a quick program
> that checks what files an application opens (this is not in anyway
> production ready):
> 
>   http://rostedt.org/code/show-open-files.c
> 
> > But we would prefer not to break anything.
> 
> Of course!
> 
> And again, I would be happy to help out in converting to this libraries. It
> will make your applications more robust, as they make it so that you do not
> need to rely on the order of fields.
> 
> Note, there's plans on making these libraries python modules as well (to
> have python scripts enable and read ftrace data).
Thanks a lot for your insightful comments.
We will surely look into libtraceevent and libtracefs

Thanks,
Avri
> 
> -- Steve