[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160115194913.GH18367@kernel.org>
Date: Fri, 15 Jan 2016 16:49:13 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Stephane Eranian <eranian@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Namhyung Kim <namhyung@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
"ak@...ux.intel.com" <ak@...ux.intel.com>
Subject: Re: [RFC] perf record: missing buildid for callstack modules
Em Fri, Jan 15, 2016 at 10:58:48AM -0800, Stephane Eranian escreveu:
> On Fri, Jan 15, 2016 at 1:34 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Thu, Jan 14, 2016 at 05:59:48PM -0800, Stephane Eranian wrote:
> >> Peter,
> >>
> >> On Thu, Jan 14, 2016 at 3:36 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> >> > On Thu, Jan 14, 2016 at 12:27:34PM +0100, Ingo Molnar wrote:
> >> >> > + * u32 filename_len;
> >> >> > + * char filename[2+];
> >> >
> >> >> Acked-by: Ingo Molnar <mingo@...nel.org>
> >> >
> >> > except of course that sizeof(u32) == 4 :/
> >
> >> There is no padding here. Are you concerned about running out of bits
> >> in filename_len?
> >
> > No, I just made a mess of it :-)
> >
> > filename_len should have been u16 and filename should then be 6+8n in
> > size.
> >
> why don't you make it more explicit:
> u16 filename_len
> u16 extra_len
> then it would be clear what is what, no field with dual meaning.
> Now, that assumes that no pathname can be longer than 65535 bytes.
There is no requirement for the filename to start at a u64 boundary,
right? So it can start right after the filename_len, be it u16 or u32,
and that extra_len can be computed as Peter described right here:
> >> Any extension possible because header.size - sizeof(mmap3) -
> >> filename_len sizing what's after filename, right?
So, no need to have that extra_len :-)
Ah PATH_MAX is 4096, so I guess u16 should be enough, no?
- Arnaldo
> > Right, current MMAP records use the remaining size as the filename
> > length, but by explicitly specifying that we can add optional fields.
> >
> > These fields must be after filename_len, otherwise you'd not be able to
> > find filename_len and you could not compute the extra size. And given
> > alignment constraints it makes sense to do it after filename[].
> >
> > So suppose we wanted to also add atime and ctime, we could do.
> >
> > PERF_RECORD_MMAP3 {
> > ...
> > u16 filename_len;
> > char filename[6+8n];
> >
> > if (extra_size >= 16) {
> > u64 stime;
> > u64 ctime;
> > };
> > }
> >
> > or something like that.
Powered by blists - more mailing lists