[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABPqkBTBpMao99t407Oz1cKMAVDYEsFSLUe85DYeOzxzuhZ9hg@mail.gmail.com>
Date: Mon, 5 Dec 2011 11:24:05 -0800
From: Stephane Eranian <eranian@...gle.com>
To: Robert Richter <robert.richter@....com>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
"acme@...hat.com" <acme@...stprotocols.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"peterz@...radead.org" <peterz@...radead.org>,
"dsahern@...il.com" <dsahern@...il.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"mingo@...e.hu" <mingo@...e.hu>
Subject: Re: [PATCH] perf: make perf.data more self-descriptive (v8)
On Mon, Dec 5, 2011 at 5:23 AM, Robert Richter <robert.richter@....com> wrote:
> On 01.12.11 09:53:10, Stephane Eranian wrote:
>> On Thu, Dec 1, 2011 at 7:15 AM, Robert Richter <robert.richter@....com> wrote:
>> > I am asking this because I want to change code in a way that treats
>> > all features the same, that is just to disable the feature bit on
>> > failure and then continue anyway.
>> >
>> You need to make sure that disabling the bit is enough to still get a consistent
>> file, i.e., want to undo the effect of writing the feature to the
>> file. In the case
>> of the meta-data features I added that was easy simply lseek() back to
>> the position
>> before the call. Would that be the case with TRACE_INFO?
>
> It should be. All features can be parsed independently. Offset and
> size of a feature's data block is stored in struct perf_file_section
> right after the data block of perf.data (see perf_session__write_
> header()). Thus, if a feature does not exist then other features can
> be processed anyway.
>
The one thing I realized last week, is that all that header information, incl.
the features bits do not seem to appear in the file perf.data file when you
use the perf record pipe mode. We need to fix that otherwise, if you
depend on information in those bits, it won't always be present. That's
a major issue.
--
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