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). -- Steve
