[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87d1gkig3w.fsf@xmission.com>
Date: Thu, 22 Dec 2016 20:21:23 +1300
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Hari Bathini <hbathini@...ux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@...radead.org>, ast@...com,
lkml <linux-kernel@...r.kernel.org>, acme@...nel.org,
alexander.shishkin@...ux.intel.com, mingo@...hat.com,
daniel@...earbox.net, rostedt@...dmis.org,
Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
sargun@...gun.me, Aravinda Prasad <aravinda@...ux.vnet.ibm.com>,
brendan.d.gregg@...il.com
Subject: Re: [PATCH v4 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info
Hari Bathini <hbathini@...ux.vnet.ibm.com> writes:
> On Wednesday 21 December 2016 06:54 PM, Peter Zijlstra wrote:
>> On Wed, Dec 21, 2016 at 06:39:01PM +0530, Hari Bathini wrote:
>>> Hi Peter,
>>>> I don't see how the tool can parse old records (with NAMESPACES_MAX ==
>>>> 7) if you set its NAMESPACES_MAX to say 10.
>>>>
>>>> Then it will expect the link_info array to be 10 entries and either read
>>>> past the end of the record (if !sample_all) or try and interpret
>>>> sample_id as link_info records.
>>>>
>>> Right. There will be inconsistency with data the perf tool tries to read
>>> beyond
>>> what the kernel supports. IIUC, you mean, include nr_namespaces field in the
>>> record and warn the user if it doesn't match with the one perf-tool supports
>>> before proceeding..?
>> Yes, if you add a nr_namespaces field its always parsable. If an old
>> tool finds more namespace than it has 'names' for it can always display
>> the raw index number. If a new tool finds the array short, it will not
>> display the missing ones.
>>
>
> Sure, Peter. Will post the next version as soon as
> I am back from vacation..
And please make the array the last item in the structure so that
expanding or contracting it does not affect the ability to read the rest
of the structure.
Eric
Powered by blists - more mailing lists