* Jovi Zhangwei <jovi.zhang...@gmail.com> wrote:
> On Fri, Apr 4, 2014 at 2:26 PM, Alexei Starovoitov <a...@plumgrid.com> wrote:
> > On Thu, Apr 3, 2014 at 6:21 PM, Jovi Zhangwei <jovi.zhang...@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.
>
> Now I understand that there is no way to integrate ktap and ibpf in
> technical point of view, the kernel side and interface is completely
> different, and obviously you don't want to change current per-event
> filter file based interface and kernel part, that make impossible to
> let ktap could integrate or share with ibpf.
In my reading that's not what Alexei wrote: he just suggested that as
long as the kernel bits are largely shared, the user-space bits
(syntax, etc.) can stay completely orthogonal and independent.
It also does not mean that ktap is forced to use the per event filter
file based interface to pass BPF scripts to the kernel. BPF is already
used by various facilities in the kernel, with different user-space
APIs to interface with it.
So the main technical question is: why should ktap have its own
separate in-kernel code execution engine, if we already have the BPF
virtual machine (which is well-maintained, has excellent performance
through JIT, etc.), which could be reused and/or enhanced?
Is there any aspect of ktap's virtual machine that BPF does not have?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
