[PATCH] [RFC PATCH] BPF backend

[Joerg Sonnenberger]

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.

Joerg