lkml.org 
[lkml]   [2008]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 1/3] Unified trace buffer

    * Steven Rostedt <rostedt@goodmis.org> wrote:

    > > > Or if we already have the data together:
    > > >
    > > > ring_buffer_write(buffer, event_id, length, data);
    > >
    > > Don't like the event_id, just stick to plain binary data, and leave
    > > interpretation open to whoemever uses it.
    >
    > This is up to debate. I know you don't like this extra event layer,
    > but seriously, all my uses with ring buffers has had some kind of
    > event. But then I'm sure you can argue that if you are using a single
    > type you can can the event.
    >
    > I'm open to doing this, but I would like a consensus on this.
    >
    > Martin, Thomas, Ingo, Linus?

    i'd prefer Peter's simplification and not pass event_id along. Since
    static types are lost anyway (which is the biggest cost and risk of any
    such abstraction), we have to convert between types early on. Whether
    event_id is visible in the API is no big difference.

    (It might be cheaper to not pass it along even if everyone ends up using
    it - as it has no semantic meaning anyway.)

    pretty much the only generic tracing information is time and payload
    size. ( but even a time key is debatable - there are various resolutions
    needed by different usecases. Some usecases are even fine without any
    timestamps at all - they just want to know the ordering of events and
    that's it.)

    i'd like to see some automatic type protection though, as an
    off-by-default debug option: encode the record type on storing and
    double-check it on extraction. So it should be possible to reliably
    store/restore a typed trace buffer and notice corruption early in
    testing.

    because there's one thing that is far more important tracer feature than
    sheer performance: robustness.

    Automated type checking in debug mode would also mean we could go for
    RLE encoding much more agressively. Most of the risks of a more complex,
    more compressed and pointer-laden data format come from type mismatches
    and the loss of compiler protection against human errors/stupidity.
    (running off the end of the page, misinterpreting a pointer, a record,
    etc.)

    Ingo


    \
     
     \ /
      Last update: 2008-09-25 12:45    [W:6.685 / U:0.764 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site