From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754645AbbBBMOP (ORCPT <rfc822;w@1wt.eu>);
	Mon, 2 Feb 2015 07:14:15 -0500
Received: from mx1.redhat.com ([209.132.183.28]:35999 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752764AbbBBMOO (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 2 Feb 2015 07:14:14 -0500
Date: Mon, 2 Feb 2015 13:13:48 +0100
From: Jiri Olsa <jolsa@redhat.com>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        LKML <linux-kernel@vger.kernel.org>, David Ahern <dsahern@gmail.com>,
        Andi Kleen <andi@firstfloor.org>,
        Stephane Eranian <eranian@google.com>,
        Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH 14/42] perf record: Add --index option for building index
 table
Message-ID: <20150202121348.GE2241@krava.brq.redhat.com>
References: <1422518843-25818-1-git-send-email-namhyung@kernel.org>
 <1422518843-25818-15-git-send-email-namhyung@kernel.org>
 <20150201180635.GA6317@krava.brq.redhat.com>
 <54CF36AA.50508@intel.com>
 <20150202091554.GA1404@krava.brq.redhat.com>
 <54CF48DA.1050805@intel.com>
 <20150202100512.GA2241@krava.brq.redhat.com>
 <54CF687F.9090703@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54CF687F.9090703@intel.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Feb 02, 2015 at 02:07:27PM +0200, Adrian Hunter wrote:

SNIP

> >>
> >> Why not make it the same as all the other data. i.e. find the start and size
> >> via the index? And then just lump all the data together?
> > 
> > thats what I suggested
> 
> No, I meant really lump it all together. i.e. perf_file_header.data.size =
> total data size
> 
> > 
> >>
> >>> I guess we could workaround that by storing the 'perf_file_header::data'
> >>> as the last data section. That would require to treat it the same way as
> >>> all other data sections, but we could keep current header layout.
> >>
> >> Would it need to be last? Logically it should precede the data that depends
> >> on it.
> > 
> > i suggested this as a workaround for having features at the end of the file
> > while keeping the current perf data header
> 
> Which wouldn't be necessary if you lump it all together?

yep, that's also an option

jirka