On Mon, Jan 24, 2011 at 06:28:54PM +0100, Jean Pihet wrote: > Hi Thomas, > > On Mon, Jan 24, 2011 at 5:04 PM, Thomas Renninger <trenn@xxxxxxx> wrote: > > Hi, > > > > as I recently cleaned up the power events with > > some format/abi adjustings... > > > > I realized that it was rather easy to adjust > > the stuff in drivers/tools/perf, because there > > are some nice facilities to query which events > > are available. > > > > I looked at pytimechart, there it's not that nice > > and convenient would be some kind of version number. > > > > pytimechart can parse traces which are simply copied > > away from /sys/kernel/debug/trace and to check for > > available events and their format, one would have to > > do a separate, ugly to implement, iteration of parsing. > > > > Would it make sense to introduce a trace > > ABI version number? > > It would be enough to increase it by one every time > > any event (don't know about other perf facilities) is > > added, removed or modified. > > Ideally the modifications are tracked with a short > > description in a file like Documentation/trace/format.changes > > > > Untested, but the patch at the end should simply add > > a version number on top of > > /sys/kernel/debug/trace file > > If needed the ABI versioning should at least contain a major and minor > number, i.e. 'x.y'. > > The big question IMO is if it is needed or not. Is this a real problem > in the userland? Are the apps always fitting the kernel ABI in a > packaged distro? This may help solving some tracepoint ABI issues that we have. But let me add more tracing people and LKML in Cc in an answer to the explanation of the idea, to discuss that more widely. -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|