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 13:41:29 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Mathieu Poirier <mathieu.poirier@...aro.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

Em Tue, Feb 02, 2016 at 09:20:51AM -0700, Mathieu Poirier escreveu:
> [...]
> 
> >>> >
> >>> > 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?

I'd say go with something we can test, i.e. if we generate a perf.data
file we can't then process to figure out if what was inserted is right,
how can we decide if it is ok?

Otherwise please describe how you test it, preferably by having this in
the commit log, i.e. if you decide that using plain 'perf report -D' is
enough, state that and show the output, etc.

- Arnaldo