[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=ssMY8615j1dXJPfK-awZnFSVn4tjLHh4Mnv4C@mail.gmail.com>
Date: Tue, 15 Mar 2011 17:33:34 -0700
From: David Sharp <dhsharp@...gle.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Slava Pestov <slavapestov@...gle.com>,
linux-kernel@...r.kernel.org, mrubin@...gle.com
Subject: Re: [PATCH] ftrace: add 'version' special file for ring buffer format
On Mon, Mar 14, 2011 at 7:31 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Mon, 2011-03-14 at 15:42 -0700, Slava Pestov wrote:
>> The intention here is that if the ftrace ring buffer format changes
>> in the future like it did in the past with ktrace, we can increment
>> the version number and update clients appropriately.
>
> I purposely avoided "versions", and instead use the
> tracing/events/header_page and .../header_event to describe how the ring
> buffer format is laid out. If the format changes, then so should those
> files.
>
> -- Steve
Those are useful files, but do not encompass the entirety of the API.
Specifically, they do not encode the semantics of those values, nor
the control interface.
For example, when the ring buffer header changed from type:2;len:3 to
type_len:5, while this would have been reflected in header_event, how
to interpret the different versions is not something that could be
automatically understood by a parser.
These files also do not cover the semantics of the control files. For
example, it is imaginable that buffer_size_kb could be changed from
per-core size to a total size, or that it would reflect the actual
total amount of memory used, instead of the "non-header" space. The
grammar of filter expressions is another example of something that
could change without notice.
d#
>
>>
>> Tested: Verified that special file contains correct content
>>
>> This patch is against 2.6.38-rc8 but should apply to any version
>> from at least 2.6.34 onwards.
>>
>> Signed-Off-By: Slava Pestov <slavapestov@...gle.com>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists