On Wed, Sep 20, 2017 at 04:49:44PM +0100, Kim Phillips wrote:
Tor Jeremiassen tor@ti.com wrote:
project [4]. Instead, this patch set includes the necessary code and build settings to interfaces to the decoder library, as well as a "stub" or
"null"
library for the case when the perf tool is built without the library.
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?
I can't see why people would insist on having the library be upstreamed, it's not something that exists solely for the kernel. CoreSight is something that any ARM system can use if it's got appropriate hardware built in, the goal is for people to be able to share the decoding code between all kinds of tools running on many OSs. perf is one such application but far from the only one, and it's still usable without the trace decode.
If there were no reasonable possibility of the library being used outside of the kernel or it were so fundamental to building kernels that it were essential then it'd be possible people would feel a need to duplicate it, but even then we'd probably do as we do with dtc and have a copy of the code rather than first class kernel code. As it is it's an optional feature and seems closer to things like some of the kselftests which happily use external libraries installed on the system.