[lkml]   [2008]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: LTTng kernel integration roadmap, update

On Mon, 24 Nov 2008, Mathieu Desnoyers wrote:
> The key idea behind this is to answer to Thomas Gleixner concerns, who
> supports that a tracer should output data in text-format only so it can
> be used with tools kernel developers have on their system, like "cat".
> However, getting data out of the kernel efficiently simply cannot be
> done with such approach. Therefore, LTTng needs its own userspace tools
> to splice the data out of the kernel efficiently. Another tool is used
> to pretty-print the binary data into text.
> Then the problem becomes : we have to make the userspace tool easy
> enough to deploy so even Linus can find and use it. ;)
> But indeed, the trace buffers are versioned, so if the format changes
> between kernel versions, the userspace tools will detect it and the user
> will know it must update its tools. So it's not really a problem there.
> The question that prevails is therefore : should we ship userspace
> binary with the kernel tree at all ? And if yes, how should the resuting
> executables be packaged and deployed ? Should it be installed in the
> system along with kernel modules or should it be populated into a
> filesystem populated by kernelspace ?
> Or is it better to do as we have always done and keep the userspace
> tools separated from the kernel tree ?

I say keep the user space tools separate as much as possible.

What about having a meta-data file for all binary files. This meta-data
could explain the format that is read. Big endian, little endian, the
fields and offsets, the event ids etc. This way we will not need a
"version" file, which means absolutely nothing if you do not know what
comes with that version. Any tool could look at the meta-data file and
figure out what is in the buffers.

-- Steve

 \ /
  Last update: 2008-11-24 18:01    [W:0.104 / U:1.644 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site