Re: ktap and ebpf integration

[Ingo Molnar <mingo@kernel.org>]

* Alexei Starovoitov <ast@plumgrid.com> wrote:

> On Thu, Apr 3, 2014 at 6:21 PM, Jovi Zhangwei <jovi.zhangwei@gmail.com> wrote:
> > Hi Alexei,
> >
> > We talked a lot on ktap and ebpf integration in these days,
> > Now I think we can put into deeply to thinking out some
> > technical issues in there.
> >
> > Firstly, I want to make sure you are support this ktap and
> > ebpf integration direction, I aware you have ongoing 'bpf filter'
> > patch set work, which actually overlapping with ktap integration
> > efforts (IMO the interface should be unified and simple for user,
> >  so I think filter debugfs file is not a good interface), so please let
> > me know your answer about this.
> 
> I think the more choices users have the better.
> I'll continue with C based filters and you can continue with ktap
> syntax. That's ok. We can share all kernel pieces.

I'd somewhat agree with that if this wasn't about the kernel, but I 
think that it's evidently useful to have one syntax for the kernel 
(both the scheduler and drivers are written in C) - and probing the 
kernel is really very close to the kernel source itself so it's just 
an extension of that same principle.

Look at the advantages: people who learn how to write C syntax ktaps 
would only be a very small step away from writing actual kernel 
patches and becoming contributors.

With some random weird new syntax (be it Lua, C# or Java or any other 
simplified syntax) that has no relation to kernel source syntax, 
there's no such synergy!

If the 'ktap syntax' lives purely in user space, and the kernel bits 
are largely be shared and reused, which your suggested design is, then 
I have no fundamental objections to that: other than I think it's a 
mistake to not harmonize with the syntax of the probed project! But as 
long as the other desing aspects are fixed it's not a big showstopper 
as the mistake is not propagated to the kernel.

> [ design suggestions ]

I fully agree with your suggestions so far, that looks like a workable 
way to address my concerns.

Thanks,

	Ingo