From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754594AbcAOTtX (ORCPT ); Fri, 15 Jan 2016 14:49:23 -0500 Received: from mail.kernel.org ([198.145.29.136]:47429 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750742AbcAOTtV (ORCPT ); Fri, 15 Jan 2016 14:49:21 -0500 Date: Fri, 15 Jan 2016 16:49:13 -0300 From: Arnaldo Carvalho de Melo To: Stephane Eranian Cc: Peter Zijlstra , Ingo Molnar , Namhyung Kim , LKML , Jiri Olsa , Namhyung Kim , Adrian Hunter , "ak@linux.intel.com" Subject: Re: [RFC] perf record: missing buildid for callstack modules Message-ID: <20160115194913.GH18367@kernel.org> References: <20160112161027.GN6357@twins.programming.kicks-ass.net> <20160112162719.GX6373@twins.programming.kicks-ass.net> <20160112171517.GI18367@kernel.org> <20160113102107.GA9644@gmail.com> <20160113124039.GA3421@worktop> <20160114112733.GB17869@gmail.com> <20160114113617.GX6357@twins.programming.kicks-ass.net> <20160115093436.GG3421@worktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Fri, Jan 15, 2016 at 10:58:48AM -0800, Stephane Eranian escreveu: > On Fri, Jan 15, 2016 at 1:34 AM, Peter Zijlstra 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 wrote: > >> > On Thu, Jan 14, 2016 at 12:27:34PM +0100, Ingo Molnar wrote: > >> >> > + * u32 filename_len; > >> >> > + * char filename[2+]; > >> > > >> >> Acked-by: Ingo Molnar > >> > > >> > 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.