[PATCH] [RFC PATCH] BPF backend

[Alexei Starovoitov]

On Thu, Dec 4, 2014 at 5:38 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Thu, Dec 04, 2014 at 05:15:22AM -0800, Chandler Carruth wrote:
>> On Thu, Dec 4, 2014 at 3:56 AM, Joerg Sonnenberger <joerg at britannica.bec.de>
>> wrote:
>>
>> > On Wed, Dec 03, 2014 at 03:07:41PM -0800, Alexei Starovoitov wrote:
>> > > On Wed, Dec 3, 2014 at 2:44 PM, Joerg Sonnenberger
>> > > <joerg at britannica.bec.de> wrote:
>> > > > On Wed, Dec 03, 2014 at 03:08:17AM +0000, Alexei Starovoitov wrote:
>> > > >> recently linux gained "universal in-kernel virtual machine" which is
>> > called
>> > > >> eBPF or extended BPF. The name comes from "Berkeley Packet Filter",
>> > since
>> > > >> new instruction set is based on it.
>> > > >
>> > > > I'd prefer if the backend name matches that, e.g. eBPF and not BPF.
>> > >
>> > > What had similar discussion in kernel and common agreement was to use
>> > > just BPF everywhere. In all macros, filenames, system call, etc.
>> > > It will be extremely confusing to users when they can do 'man bpf'
>> > > and #include <bpf.h>, but to select correct llvm backend they
>> > > would have to specify -march=ebpf...
>> >
>> > It will be just as confusion for users on any non-Linux system to
>> > discover that the created BPF is not really BPF. I blame the Linux folks
>> > for overloading the name.
>>
>>
>> I think it is essentially nuts to for folks that aren't contributing to
>> Linux to try to argue with the Linux folks about the name they chose for
>> their feature. ;]
>
> This is not about the Linux kernel. If they want to confuse their users,
> I could care less. The BPF VM has been around for over 23 years.
> Introducing a "BPF" backend which does not work for something compatible
> is bad. To apply the confusing argument: BPF support in one form or
> another exists for pretty much *all* platforms that can host LLVM --
> Windows, Linux, BSD.

btw, classic BPF VM was replaced with this extended BPF VM
in kernel starting 3.15.
Kernel still supports classic instructions as an input, verifies it
and converts to eBPF. So 23 year old VM is gone.
Also even classic BPF was quite a bit incompatible between
BSD and Linux. Linux had its own extensions and ways to
load it. Linux has seccomp which is yet another specialized
extension. $ls in libpcap
  39771 pcap-common.c
171377 pcap-linux.c
kinda tells that even if it was possible to have a backend
for classic instruction set, it likely would be specific to an OS.

eBPF instruction set is free and can be used by any OS.

If there are concerns that this backend does
nothing for BSD today, we can make it selectable on linux only.
I don't expect folks to cross compile from bsd to linux anyway.
Less testing for me as well :)