Re: [PATCH 10/11] perf tools: Add probing for udev86 library

[Ingo Molnar]

* Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote:

> > 
> > Yeah, so udis86 also seems to be a pretty old, relatively stale library with no 
> > support for new instructions AFAICS.
> 
> There are lots of new instructions in pull requests on github.
> 
> But yes the author seems to be a bit slow in pulling.
> 
> > 
> > So I'd rather encourage librarizing one of the x86 instruction decoders in 
> > arch/x86/, and adding pretty-printing functionality to it. The code can already 
> > see instruction boundaries, which is the hardest part.
> > 
> > That would also be better supported on non-x86 architectures in the long run:
> > 
> >  triton:~/tip> find arch/ -name insn.c | xargs ls -l
> >  -rw-rw-r-- 1 mingo mingo 30244 Mar 29 11:24 arch/arm64/kernel/insn.c
> >  -rw-rw-r-- 1 mingo mingo  1347 Dec  8 06:27 arch/arm/kernel/insn.c
> >  -rw-rw-r-- 1 mingo mingo 15123 Mar 30 12:31 arch/x86/lib/insn.c
> > 
> > Such an in-kernel-repo library could also be used by live kernel debuggers such as 
> > kgdb/kdb, oops/crash-time disassembly printout, etc.
> > 
> > ... so how about that direction instead?
> 
> It's a major project. Who is gonna work on it? Are you volunteering?

As a maintainer I don't have much free time and me writing code for every 
technical disagreement doesn't scale in any case, but I'm responsible for creating 
the environment and incentives for people to eventually work on such enhancements.

My main tool to create such an environment is to convince people, if that tool 
doesn't work then my secondary tool is to say 'no'. If we merge udis86 support we 
remove one big incentive for people to factor out and enhance the already existing 
in-kernel disassemblers - not good.

Also, you are exaggerating the technical difficulties a lot (which is sadly a well 
known modus operandi of yours when you don't get your way in technical 
discussions, and which conflicts with the Linux project's 'can do' attitude 
frequently), I've seen in-kernel disassembler pretty-printing patches on lkml as 
well, so clearly it's possible and desirable.

Thanks,

	Ingo