Re: Unified tracing buffer

From: Martin Bligh
Date: Tue Sep 23 2008 - 14:27:59 EST


On Tue, Sep 23, 2008 at 10:55 AM, K.Prasad <prasad@xxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Sep 23, 2008 at 07:00:38AM -0700, Martin Bligh wrote:
>> > - get rid of anything having to do with padding, nobody needs it and its
>> > only affect has been to horribly distort and complicate a lot of the
>> > code
>> > - get rid of sub-buffers, they just cause confusion
>> > - get rid of mmap, nobody uses it
>> > - no sub-buffers and no mmap support means we can get rid of most of the
>> > callbacks, and a lot of API confusion along with them
>> > - add relay flags - they probably should have been used from the
>> > beginning and options made explicit instead of being shoehorned into the
>> > callback functions.
>>
>> Actually, I think if you did all that, it'd be pretty close to what we
>> want anyway ...
>
> In the perspective of having a layered infrastructure, can we consider
> the interfaces later added over relay (to be used as a wrapper), namely
> relay_printk() and relay_dump()?

Might well work, but let's see what relayfs comes out looking like.
If it's heavily simplfiied, hopefully people will like it.

> - Very minimal work required to log data using the interfaces. Usage is
> made simple to resemble the printk(). Like
>
> struct relay_printk_data *tpk;
> tpk->parent_dir = "PARENT";
> tpk->dir = "DIR";
> relay_printk(tpk, <String to be output>);
> relay_dump(tpk, <Some binary data to output>);

You really don't want to store strings in the buffer, it's horribly
inefficient. I think the intent was to store binary data from tagged
events, along with the format strings, and do all the expansion later.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/