Forgot to reply 'all'.
-----Original Message----- From: Jeremiassen, Tor Sent: Wednesday, September 20, 2017 10:58 AM To: 'Kim Phillips' Subject: RE: [EXTERNAL] Re: [PATCH v7 00/22] Add support for CoreSight trace decoding
I think one reason for not upstreaming the decoder library itself is that it has applications outside of perf and the linux ecosystem. As you know Arm trace has been used across a large range of ARM embedded processors to support embedded software development. As such, the need for a trace decoder isn't new. However, within an embedded toolchain the actual trace decoder really doesn't provide a real value add for any software tools provider, it's more what you do with the trace output. Therefore, having an open sourced generic ARM trace decoder is useful in a much broader range of use cases than processing traces within perf. Additionally, the perf use case primarily centers on collecting traces on the Cortex-A processors, while the open source trace decoder should have as a goal to provide decoding support to both M-class and R-class ARM processors, though priorities may dictate the order in which such support is added.
My concern is that making the trace decoder library of the source tree would jeopardize the broader use case in favor of a Cortex-A linux focused solution, and fail to provide a single open sourced decoder library across the ARM cores.
This being said, I agree that this would need to be communicated more clearly in the write-up.
Best regards,
Tor Jeremiassen
-----Original Message----- From: Kim Phillips [mailto:kim.phillips@arm.com] Sent: Wednesday, September 20, 2017 9:10 AM To: Al Grant Cc: Jeremiassen, Tor; coresight@lists.linaro.org Subject: [EXTERNAL] Re: [PATCH v7 00/22] Add support for CoreSight trace decoding
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.]
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.
Kim