linux-kernel - Re: [PATCH RFC 1/2] perf tools: Support single perf.data file directory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9b283364-0d58-40c0-80ff-b01c31cafd0f@intel.com>
Date:   Tue, 24 Sep 2019 14:51:28 +0300
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/2] perf tools: Support single perf.data file
 directory

On 24/09/19 2:12 PM, Jiri Olsa wrote:
> On Tue, Sep 24, 2019 at 12:12:25PM +0300, Adrian Hunter wrote:
>> On 24/09/19 12:34 AM, Jiri Olsa wrote:
>>> On Mon, Sep 16, 2019 at 11:56:45AM +0300, Adrian Hunter wrote:
>>>> Support directory output that contains a regular perf.data file. This is
>>>> preparation for adding support for putting a copy of /proc/kcore in that
>>>> directory.
>>>>
>>>> Distinguish the multiple file case from the regular (single) perf.data file
>>>> case by adding data->is_multi_file.
>>>
>>> SNIP
>>>
>>>>  static int open_file_read(struct perf_data *data)
>>>>  {
>>>>  	struct stat st;
>>>> @@ -302,12 +312,17 @@ static int open_dir(struct perf_data *data)
>>>>  {
>>>>  	int ret;
>>>>  
>>>> -	/*
>>>> -	 * So far we open only the header, so we can read the data version and
>>>> -	 * layout.
>>>> -	 */
>>>> -	if (asprintf(&data->file.path, "%s/header", data->path) < 0)
>>>> -		return -1;
>>>> +	if (perf_data__is_multi_file(data)) {
>>>> +		/*
>>>> +		 * So far we open only the header, so we can read the data version and
>>>> +		 * layout.
>>>> +		 */
>>>> +		if (asprintf(&data->file.path, "%s/header", data->path) < 0)
>>>> +			return -1;
>>>> +	} else {
>>>> +		if (asprintf(&data->file.path, "%s/perf.data", data->path) < 0)
>>>> +			return -1;
>>>> +	}
>>>
>>
>> Thanks for replying :-)
>>
>>> first, please note that there's support for perf.data directory code,
>>> but it's not been enabled yet, so we can do any changes there without
>>> breaking existing users
>>>
>>> currently the logic is prepared to have perf.data DIR_FORMAT feature
>>> to define the layout of the directory
>>>
>>> it'd be great to have just single point where we get directory layout,
>>> not checking on files names first and checking on DIR_FORMAT later
>>
>> Ok, but what are you suggesting?  Naming the data file "header" seems a bit
>> counter-intuitive in this case.
> 
> don't know ;-)

So what about calling it "data" instead of "header"?

> 
> but I'd like to have one way of finding out the directory layout
> 
> the code for threaded record uses DIR_FORMAT feature value
> to ensure the directory contains the expected files, which
> is data file with 'data.<cpu>' name for every cpu
> 
>>
>>>
>>> also the kcore will be beneficial for other layouts,
>>> so would be great to make it somehow optional/switchable
>>
>> In these patches it is, because it is not related to the DIR_FORMAT.
>>
>>> one of the options could be to have DIR_FORMAT feature as the source
>>> of directory layout and it'd have bitmask of files/dirs (like kcore_dir)
>>> available in the directory
>>
>> Is there an advantage to making optional files/dirs part of the format?
>> i.e. if they are there, use them otherwise don't.
> 
> ok, that might work, but please make that somehow explicit/visible
> what files/directories are possible in the directory, so we could
> easily see them and add new ones

At the moment, what can exist is what can be removed i.e. see
rm_rf_perf_data().  Will that do?