[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150901145012.GC29821@kernel.org>
Date: Tue, 1 Sep 2015 11:50:12 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: "Wangnan (F)" <wangnan0@...wei.com>
Cc: 平松雅巳 / HIRAMATU,MASAMI
<masami.hiramatsu.pt@...achi.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
He Kuang <hekuang@...wei.com>,
Alexei Starovoitov <ast@...mgrid.com>,
Brendan Gregg <brendan.d.gregg@...il.com>,
Daniel Borkmann <daniel@...earbox.net>,
David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...nel.org>,
Kaixu Xia <xiakaixu@...wei.com>,
Namhyung Kim <namhyung@...nel.org>,
Paul Mackerras <paulus@...ba.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Zefan Li <lizefan@...wei.com>,
"pi3orama@....com" <pi3orama@....com>
Subject: Re: [PATCH 23/31] perf tools: Introduce regs_query_register_offset()
for x86
Em Tue, Sep 01, 2015 at 09:52:30PM +0800, Wangnan (F) escreveu:
> On 2015/9/1 19:47, 平松雅巳 / HIRAMATU,MASAMI wrote:
> >>From: Wang Nan [mailto:wangnan0@...wei.com]
> >>regs_query_register_offset() is a helper function which converts
> >>register name like "%rax" to offset of a register in 'struct pt_regs',
> >>which is required by BPF prologue generator. Since the function is
> >>identical, try to reuse the code in arch/x86/kernel/ptrace.c.
> >>Comment inside dwarf-regs.c list the differences between this
> >>implementation and kernel code.
> >Hmm, this also introduce a duplication of the code...
> >It might be a good time to move them into arch/x86/lib/ and
> >reuse it directly from perf code.
> So you want to move it from ./arch/x86/kernel/ptrace.c to arch/x86/lib and
> let perf link against arch/x86/lib/lib.a to use it?
> I think it worth a specific work to do it. Currently we lake
> scaffold to compile and link against the kernel side library. Moreover,
> we should also consider other archs. Seems not very easy.
> This is not the only one file which can benifite from kernel's arch/x86/lib
> Newly introduced tools/perf/util/intel-pt-decoder/insn.c, and I believe
> there's
> more. Therefore I think it should be a separated work from perf BPF patches.
> So how about keep this patch at this time? Or do you have some idea?
I would go with what Wang did at this time, its a step in the right
direction in the sense that we're trying to use the same function names
and semantics, and, as much as possible, possibly in verbatim form,
using the same implementation.
Doing the work to fully share it is something being discussed, but that
should not get in the way of eBPF work, IMHO.
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists