linux-kernel - Re: [PATCH V8 23/23] perf tools: adding coresight etm PMU record capabilities

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]

Date:	Tue, 2 Feb 2016 09:20:51 -0700
From:	Mathieu Poirier <mathieu.poirier@...aro.org>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	Adrian Hunter <adrian.hunter@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH V8 23/23] perf tools: adding coresight etm PMU record capabilities

[...]

>>> >
>>> > Looks OK, apart from adding linux/coresight-pmu.h to the manifest, but I
>>> > mentioned that on another patch.
>>> >
>>> > However there is no decoder, which begs the question, is there anything you
>>> > can actually do with the perf.data file?  Might be a bit confusing for users
>>> > if they can capture traces but not use perf tools on the resulting perf.data
>>> > file?
>>>
>>> We are working on a decoding library in parallel to this work.
>>
>> Would be nice to be able to get both in the same patch kit, no? So that
>> one can both record and process the traces, verifying it all works.
>
> We are still a few weeks away from being in a position where the
> community can start playing with the decoding library.  I can hold off
> on the "perf tools" patches when I queue the kernel side of the work
> for 4.6 but since you and Adrian have already reviewed the work it
> would be nice to have that part included as well.
>
> We've been playing with the perf.data files for a couple of months now
> and things look at the right place.  This isn't surprising since we
> are using the same framework as X86.
>
> I think the generation of the perf.data file should be coupled with
> the submission of the kernel driver but would also respect a diverging
> point of view.  Simply let me know what you prefer and I will adjust
> V9 accordingly.

Arnaldo,

I'm preparing V9 at this time - what's your view on the above?

Thanks,
Mathieu