Le 26 sept. 2016 8:47 PM, "Alexei Starovoitov" <alexei.starovoitov@xxxxxxxxx <mailto:alexei.starovoitov@xxxxxxxxx>> a Ãcrit :
>
> 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.
++1
>