[PATCH] [RFC PATCH] BPF backend

[Chandler Carruth]

And if we ever wanted to support it, would it not be the same backend with
two subtargets? And to me that argues for BPF...

And I'm just not really sure who the confused folks are going to be as I've
not yet seen anyone asking for raw bpf support...
On Dec 4, 2014 5:40 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.
>
> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141204/cfff1654/attachment.html>