On Wed, Sep 20, 2017 at 03:54:14PM -0500, Kim Phillips wrote:
If it helps to clarify my position, I'm not saying the ETM trace decoder / OpenCSD library / master branch should necessarily be converted to move *away* from where it is, and live *solely* in the kernel tree's perf tool sources: I'm asking what if the maintainers didn't want to have to depend on external libraries for Coresight report support.
If that is an issue for the perf maintainers I'm sure they will be more than capable of bringing it up themselves and as I said in the message to which you are replying there is an existing approach to this:
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
which has served us well.
I don't know how optional or not Coresight report is - I'll leave that up to the upstream maintainers, but, I will say that perf report with Intel PT input currently runs on Arm perf binaries, and there is no option to opt-out of it, so the upstream maintainers, sure, whilst being a little Intel-centric, nevertheless made the decision that any perf binary should be able to decode a perf.data file from another arch.
I think you may be reading far too much into this and that it may be a much less deliberate or considered decision than you seem to see it as, parallel implementation (perhaps due to difficulty in reuse due to things being tied too closely to the rest of the implementation) or just poor communication are also possible.