On Wed, 20 Sep 2017 08:32:54 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 20 September 2017 at 08:09, Kim Phillips kim.phillips@arm.com wrote:
On Wed, 20 Sep 2017 02:20:38 -0500 Al Grant Al.Grant@arm.com wrote:
I seriously doubt this would be acceptable upstream: they prefer to have all code fully-inclusive. Do we have a plan for somehow upstreaming the library, or some other means for working around this restriction?
They may prefer it that way but they have already accepted an out-of-tree dependency in the Python interpreter, and OpenCSD could be done that way. I.e. provide a NO_LIBOPENCSD alongside NO_LIBPYTHON. Make it as straightforward as possible to build in the decoder and encourage distributions to do this (which they don't necessarily do with Python).
A Python interpreter is a well-recognized requirement for many pieces of software, in this case, some optional advanced scripting features in perf.
OpenCSD is a proprietary h/w trace decoder, necessary for perf to decode what it recorded into perf events that can then get reported, injected, etc. Intel's decoders (and disassemblers even) are fully included into the perf sources.
[Note that perf report should run on any arch and correctly interpret any *other* arch's perf.data files, so an Arm arch perf binary should be able to run an inject on an Intel PT perf.data file, and vice versa.]
Patches are always appreciated.
I know they are, but can't tell what you're getting at in this particular context.
OpenCSD is nowhere near as ubiquitous as python, and will take some time to be included in distributions, and that's if it's meaningful to do so: Is there some other purpose than perf ETM aux decode that the distribution keepers will be convinced of? I'm not aware of any, and if it's only for perf, I wouldn't be surprised if the distributions didn't ask why we wouldn't include it directly into perf's sources in the first place.
Not saying upstreaming the library into the kernel is necessarily wrong, just that perf already accepts the idea of an out-of-tree dependency.
I don't see a proprietary h/w trace decoder being among them, but we can talk about this all day.
Instead, there is one way we can find out whether it'll be accepted for sure: by submitting at least the first patch of this series "perf tools: Add initial hooks for decoding coresight" as an RFC or whatever to the upstream perf tool maintainers (acme, etc.). The sooner we do that, the less time we'll spend speculating about it.
Support for perf record will go out as a patchset so that people can see that a full solution is available.
I thought this was about perf report, not record? The degree of the perf report solution ('full' or otherwise) depends on the degree of perf integration with the decoder.
As for including the library in the kernel tree I am happy to welcome new resources to the team. Otherwise and as stated last week, we do not have the resources.
Let's see how the upstream perf tool maintainers respond to this patchseries - or at least patch 1 of 22 - before discussing resources (which probably belongs off-list anyway).
Kim