Hi Joe, Steven, On Tue, Sep 10, 2019 at 12:44:03PM -0700, Joe Perches wrote: > On Tue, 2019-09-10 at 15:03 -0400, Steven Rostedt wrote: > > On Tue, 10 Sep 2019 11:42:06 -0700 > [] > > > btw: > > > > > > Is there kernel version information available in > > > trace output files? > > > > Not really. This is just a library that parses the trace event formats, > > there's not kernel versions passed in, but we do use variations in > > formats and such to determine what is supported. > > > > > If so, it might be reasonable to change the tooling > > > there instead. > > > > > > > Actually, I think we could just look to see if "%pfw" is used and fall > > to that, otherwise consider it an older kernel and do it the original > > way. > > Well, if you think that works, OK great. > > But could that work? > How would an individual trace record know if > another trace record used %pfw? > > Perhaps not reusing %pf, marking it reserved > for a period of years, and using another unused > prefix %p<type> like %pnfw may be simpler.
%p[Ff]w does not exist (I grepped for it) in older kernels since v3.0. So kernel support for %p[fF] and %pfw are mutually exclusive. If you're ok with that, I could change the patch to check %pf isn't followed by 'w', in order to support %pf on older kernels. Although that still does not address using older tooling on newer kernels with support for %pfw. If you think that's an issue, I'll opt for another extension than %pfw, which I chose originally since it's memorable --- fw for fwnode (names, paths, and probably more in the future). -- Regards, Sakari Ailus sakari.ai...@linux.intel.com
