Re: [PATCH V2 12/15] perf tools: allow non-matching sample types

From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Stephane Eranian <eranian@google.com>,
	David Ahern <dsahern@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Jiri Olsa <jolsa@redhat.com>, Mike Galbraith <efault@gmx.de>,
	Namhyung Kim <namhyung@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH V2 12/15] perf tools: allow non-matching sample types
Date: Mon, 26 Aug 2013 15:54:49 -0300	[thread overview]
Message-ID: <20130826185449.GA8765@ghostprotocols.net> (raw)
In-Reply-To: <CABPqkBQar4SKq_A+=ShdjJgYfxW90yuD=M=WQ2HjFwR_bKxKkg@mail.gmail.com>

Em Wed, Jul 03, 2013 at 08:44:25AM +0200, Stephane Eranian escreveu:
> On Tue, Jul 2, 2013 at 9:09 AM, Adrian Hunter <adrian.hunter@intel.com> wrote:
> > It would be more compelling to provide a use-case where that "waste"
> > actually makes any difference.

> In my opinion, it's not so much of the "wasted" space than on the ease of use
> for tools. With your change, tools would have to know something about the order
> in which sample_type is laid out. And it just happens that it is not
> as trivial as
> expected. It is NOT the bit position order in sample_type. So this is more error
> prone.

> I prefer your IDENTIFIER solution better, yet it also implies that this flag is
> special. It provides the event ID at the first position in the sample's body.

I'm trying to process Adrian's latest batch, but then I saw this
discussion and since this compat part is the first patch and is
controversial, i.e. Stephane seems to be against it as is David Ahern, I
would like to get this compat thing to be moved to the end of the
patchset, so that we could get the parts that everybody agrees should go
in first and then further discuss the merits of forcing the
compatibility up to where we can get the PERF_SAMPLE_ID info.

Sorry Adrian, this has been thru a lot of versions :-\

I tried doing it myself, but in the end you would have to take a look to
see if I hadn't messed up something, so if you can do a  v13 with 

  [PATCH V12 01/13] perf tools: allow non-matching sample types

Moved to 13/13, I could then process the other patches and move on,

Allowing mixed sample types after this part that must be force made
compatible allows us to do things in older kernels that we can't now, so
it has merits, BTW.

Thanks,

- Arnaldo