[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160926234701.GA58431@ast-mbp.thefacebook.com>
Date: Mon, 26 Sep 2016 16:47:03 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: "Wangnan (F)" <wangnan0@...wei.com>
Cc: acme@...nel.org, ast@...com, pi3orama@....com,
linux-kernel@...r.kernel.org, lizefan@...wei.com,
Arnaldo Carvalho de Melo <acme@...hat.com>,
He Kuang <hekuang@...wei.com>, Jiri Olsa <jolsa@...nel.org>
Subject: Re: [PATCH 00/14] perf clang: Support compiling BPF script use
builtin clang
On Mon, Sep 26, 2016 at 09:49:30AM +0800, Wangnan (F) wrote:
>
>
> On 2016/9/24 23:16, Alexei Starovoitov wrote:
> >On Fri, Sep 23, 2016 at 12:49:47PM +0000, Wang Nan wrote:
> >>This patch set is the first step to implement features I announced
> >>in LinuxCon NA 2016. See page 31 of:
> >>
> >> http://events.linuxfoundation.org/sites/events/files/slides/Performance%20Monitoring%20and%20Analysis%20Using%20perf%20and%20BPF_1.pdf
> >>
> >>This patch set links LLVM and Clang libraries to perf, so perf
> >>is able to compile BPF script to BPF object on the fly.
> >Nice!
> >So single perf binary won't have llvm external dependency anymore
> >or both ways will be maintained?
> >The command line stays the same?
>
> Yes. This patch set doesn't change interface. It compiles BPF script
> with builtin clang, and if it fail, fall back to external clang.
>
> >If I understand the patches correctly, this set is establishing
> >the basic functionality and more complex features coming?
> >
>
> Yes. Following steps are:
>
> 1. Ease of use improvement: automatically include BPF functions
> declaration and macros.
+1
> 2. Perf's hook: compile part of BPF script into native code, run
> them in perf when something happen. Create a channel, coordinate
> BPF and native code use bpf-output event.
+1
> 3. Define a new language to support common profiling task. I'm not
> very clear what the new language should be. It may looks like lua,
> perf converts it to C then to LLVM IR with builtin clang.
Many tracing languages were invented in the past.
At this point I'm not sure what exactly new language will solve.
To make it easier to write bpf programs?
I think it will be more fruitful to tweak clang/llvm to add
good warnings/errors for cases where we know that C is not going
be compiled into the code that the kernel verifier will accept.
Like we can complain about loops, unitialized variables,
non-inlined and unkown helper functions... all from clang/llvm.
imo that would be the better path forward and will help
both tracing and networking users that write in this restricted C.
Powered by blists - more mailing lists