[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a36f7bc-0d16-4748-63a7-c33f6b129b5a@gmail.com>
Date: Tue, 17 May 2016 21:04:38 -0600
From: David Ahern <dsahern@...il.com>
To: Hekuang <hekuang@...wei.com>, peterz@...radead.org,
mingo@...hat.com, acme@...nel.org,
alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
wangnan0@...wei.com, jpoimboe@...hat.com, ak@...ux.intel.com,
eranian@...gle.com, namhyung@...nel.org, adrian.hunter@...el.com,
sukadev@...ux.vnet.ibm.com, masami.hiramatsu.pt@...achi.com,
tumanova@...ux.vnet.ibm.com, kan.liang@...el.com,
penberg@...nel.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of
buildid dsos under symfs
On 5/17/16 8:48 PM, Hekuang wrote:
>> I don't understand why dso-prefix option is needed? Why make me type
>> yet more options to the analysis command? Why can't the directory be
>> located under the symfs tree in a known location and populated the
>> same way it is without symfs?
>>
>>
> Because the default buidid folder path is $HOME/.debug/.buildid,
> and this $HOME is on the target machine, not the same as $HOME
> on the host. Without that option, we need to copy $HOME/.debug/.buildid
> to the 'known location in symfs', that's also an extra work.
>
My argument for symfs is that $HOME is not relevant or if it is the path
is symfs/$HOME. The use case is dealing with countless images -- some
development, some production. I should be able to nuke the symfs when
the analysis is done and everything related to it is gone. With the
$HOME/.debug path it just grows on and on with no real means of pruning it.
If the vdsos are for a particular symfs then why aren't the vdso's under
it in a known location?
Powered by blists - more mailing lists