[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160331064939.GA13328@gmail.com>
Date: Thu, 31 Mar 2016 08:49:40 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
linux-kernel@...r.kernel.org,
Stephane Eranian <eranian@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...nel.org>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
Zi Shen Lim <zlim.lnx@...il.com>
Subject: Re: [PATCH 10/11] perf tools: Add probing for udev86 library
* Andi Kleen <ak@...ux.intel.com> 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
Powered by blists - more mailing lists