> > On Mon, 7 Dec 2020 16:40:51 +0000 > Avri Altman <Avri.Altman@xxxxxxx> wrote: > > > > > > > On Mon, 7 Dec 2020 07:57:27 +0000 > > > Avri Altman <Avri.Altman@xxxxxxx> 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
