[lkml]   [2018]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: heads up: moving intel-pt-decoder/Build header checks to
On 29/05/18 16:48, Arnaldo Carvalho de Melo wrote:
> Hi Adrian,
> We've made tools/perf/ the mechanism to check
> for drift on kernel file copies we have in tools/, and it assumes that
> if we have tools/a/b/c/d, then it came from a/b/c/d in the kernel
> sources, e.g. a copy of the kernel's arch/x86/lib/x86-opcode-map.txt
> would be in tools/arch/x86/lib/x86-opcode-map.txt.
> That is not the case with the intel-pt-decoder, so I'm thinking
> about moving those files to comply with the model used for other copies,
> as having it in util/intel-pt-decoder/ isn't strictly required, i.e.
> those files could conceivably be used for other purposes besides
> decoding intel-pt traces, say for disassembly/annotate, that albeit not
> planned (at least by me) for the near future, would be something
> interesting to investigate doing.
> IIRC Ingo was the one to point me out this, and now I saw the
> warning about it being different flying by in the middle of the build,
> differently from what is done by, that is to show
> everything that drifted in one single block, at the start of the build.
> So unless you have a strong objection to this, I'll continue
> investigation about how do do it with tools/perf/,

I have no objection but currently it is (theoretically) possible to compile
Intel PT decoding support into perf script and perf report for any
architecture. i.e. decoding Intel PT from a file does not depend
on the build architecture.

 \ /
  Last update: 2018-05-30 08:32    [W:0.040 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site