Hi,
Pierre may correct me if I am wrong, even pytimechart is not big,
I realized that I am not that good in python code reading...
On Monday 24 January 2011 21:12:25 Mathieu Desnoyers wrote:
> [ added Ingo, Steven, Thomas and Peter to CC list ]
>
> I would agree, though, about the need for a version number on the way
> /sys/kernel/debug/tracing/events exports the binary event type and text-output
> formatting information: in order to cope with changes to the way this metadata
> is exported, we'd need such a versioning number.
pytimechart simply works on reading /sys/kernel/debug/trace
The big advantage is that you can copy things away to another machine.
I expect the same concept is with perf record and perf.data.
Theoretically you can attach perf.data to a bug report and everybody (considering
the userspace tool is new and maintained enough) can process the data.
I do not know the binary format of this file, but a version number would be
an easy way for userspace tools to figure out which events are supported
and in which format.
> But again, trying to version every tiny change to the fields per se won't scale
> with the development process given that we pull instrumentation changes from
> many different repository concurrently. The field layout information is there to
> deal with this problem, pytimechart should perhaps start using it.
I see that there are quite some changes, but why wouldn't it scale?
Even if every git commit automatically would increases the version, a userspace
tool would only pick out very specific versions it cares about:
if (version > 2000) {
/* event x got introduced, try to catch it as well */
}
if (version < 3000) {
/* event y did not have field z */
}
...
I would not introduce a major.minor just for the sake of it.
About Frederic's comment:
> Also, tracking the changes in the Documentation is going to be a
> nightmare. I suggest developers who want to dig into details of
> an ABI change to check the code or the format themselves.
If you want an ABI and userspace tools being able to cope with
it across kernel versions , there should be some documentation as well.
Let it only be one sentence containing the event to grep for. You can then
catch the details from the git commit id.
Thomas
--
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
|