[lkml]   [2008]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ltt-dev] LTTng kernel integration roadmap, update
    * Steven Rostedt ( wrote:
    > 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.

    I'd be in favor of that too. We should just document and package it so
    it's easy to find.

    > 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

    This is exactly what I do in LTTng, modulo the fact that I repeat this
    information also in other buffer headers, but only use the information
    located in the metadata buffer header. I duplicated the information to
    make sure all subbuffer headers looks the same, but I could easily
    change that.

    I would however keep a small subbuffer header with a version number for
    each subbuffers though, just so the parser can "know" what file this is
    and what metadata should be expected with it. I think about the poor
    user who lost its metadata file and wonders what tool could open the
    other tracefiles he has... without a header containing at least a magic
    number and a version, those files won't be identified. But we can keep
    this information as minimalistic as possible.

    Thanks for the feedback.


    Mathieu Desnoyers
    OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68

     \ /
      Last update: 2008-11-24 21:49    [W:0.023 / U:9.068 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site