<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 3:56 AM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Dec 03, 2014 at 03:07:41PM -0800, Alexei Starovoitov wrote:<br>
> On Wed, Dec 3, 2014 at 2:44 PM, Joerg Sonnenberger<br>
> <<a href="mailto:joerg@britannica.bec.de">joerg@britannica.bec.de</a>> wrote:<br>
> > On Wed, Dec 03, 2014 at 03:08:17AM +0000, Alexei Starovoitov wrote:<br>
> >> recently linux gained "universal in-kernel virtual machine" which is called<br>
> >> eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since<br>
> >> new instruction set is based on it.<br>
> ><br>
> > I'd prefer if the backend name matches that, e.g. eBPF and not BPF.<br>
><br>
> What had similar discussion in kernel and common agreement was to use<br>
> just BPF everywhere. In all macros, filenames, system call, etc.<br>
> It will be extremely confusing to users when they can do 'man bpf'<br>
> and #include <bpf.h>, but to select correct llvm backend they<br>
> would have to specify -march=ebpf...<br>
<br>
</span>It will be just as confusion for users on any non-Linux system to<br>
discover that the created BPF is not really BPF. I blame the Linux folks<br>
for overloading the name.</blockquote></div><br>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. ;]</div><div class="gmail_extra"><br></div><div class="gmail_extra">If this goes in, it should follow whatever naming convention the kernel folks that designed it and work on and with it would expect and use.</div></div>