Talk:eBPF

Relation to Berkeley Packet Filter

Is this the Extended Berkeley Packet Filter? Should it be merged into Berkeley Packet Filter, or is a separate article in order? Robert McClenon (talk) 16:23, 8 September 2022 (UTC)}}

I'm not sure the fashion in which one should reply to an AfC comment, but:

1) Yes, this is about the "eBPF" that includes a pseudo-machine language, just as the original BPF does, and whose pseudo-machine language can be run in various contexts including several places in the Linux kernel, including but not limited to the filtering of network packets to be provided to a packet tap mechanism.

2) The intent appears to be to provide a separate article. One may choose to consider incorporating it into the Berkeley Packet Filter article more appropriate than having a separate article, However, as I see it:

The term "BPF" can refer either to the particular packet tap mechanism provided by some operating systems (various *BSDs, macOS, and AIX) or to the pseudo-machine language currently used for packet filter in several packet tap mechanisms, including the aforementioned "BPF" packet tap mechanism as well as the "NPF" filter mechanism in WinPcap and Npcap and the packet capture mechanism in Tru64 Unix, and also used in the Linux "socket filter" mechanism that allows packet filtering in, among other places, Linux's "PF_PACKET socket" packet tap mechanism.

Similarly, "eBPF" can refer to a pseudo-machine language similar in concept but different in detail from the BPF pseudo-machine language or to the mechanisms, or to the mechanisms that uses that pseudo-machine language to insert external code into various data paths in, for example, the Linux kernel.

The Berkeley Packet Filter page discusses both of the two uses of the "BPF" term, with Berkeley Packet Filter § Raw data-link interface discussing to the packet tap mechanism and Berkeley Packet Filter § Filtering discussing the pseudo-machine language and its use in the packet tap mechanism. If eBPF were solely a pseudo-machine language that can be used in some or all of the same places that the classic BPF's pseudo-machine language can be used, then I think a case could be made that it should be described in Berkeley Packet Filter. That was, I think, the case at one point in time. However, given that eBPF's pseudo-machine language has been extended to perform functions unrelated to packet filtering, and that I know of little if any attention being given to the classic BPF's pseudo-machine language being extended to support such unrelated uses, much less being used in such a fashion, I think a separate such page is called for here.

(If this discussion should occur on the talk page, feel free to move it there.) Guy Harris (talk) 11:56, 16 November 2022 (UTC)

eBPF does appear to meet WP:N requirements (e.g. [1], [2], [3]) so I'll go ahead and accept this. A WP:MERGE can always be performed if a separate article turns out to not be the best way to cover the topic. ~Kvng (talk) 22:25, 1 January 2023 (UTC)

The name "eBPF" and why what it stands for isn't always treated as important

A recent edit added an explanation of the character string "eBPF" to the lede, with an edit comment that says "...no idea why so many sources about this technology bury "what does the goddamn acronym stand for" 80 pages deep in their docs...".

Perhaps people should think of eBPF as being like the Holy Roman Empire; eBPF is an extension of something, but it's not from Lawrence Berkeley National Laboratory or any other institution in Berkeley (unlike the "something" of which it's an extension), and it's not (just) a packet filter, so the only letter in the name that's really meaningful is "e".

I.e., the history of the name may be interesting, but it conveys very little information, if any, about what eBPF is. Guy Harris (talk) 21:48, 10 May 2023 (UTC)

That was, to be clear, my comment, and I stand by it. I hold the radical position that words mean things. If there's an acronym or initialism, a natural first question is "what does that stand for?" When the answer to that question is "it's complicated," then we should respect that complication and try to explain it, not say "oh it's meaningless." Just because an acronym, etymology, or other naming question is complicated, doesn't mean it should be swept under the rug, and such sweeping does a disservice to Wikipedia's readers. The stewards of the eBPF project could change the name and decided not to. I think that was a shit decision on their part — as Jasonbar3121 notes, the name is misleading! — but that's their decision to make. I cannot vigorously enough reject the notion that Wikipedia should participate in misleading people by saying "the name means nothing." The name has a history and we should document that history. Documenting the history leads people truly, and ignoring it is a form of lying to Wikipedia's readers. The eBPF maintainers are the ones who are misleading people by retaining the name, and that's their problem to fix. Wikipedia should instead lead people to understand the full context of the project, its name, and everything else about it that is notable enough to include on Wikipedia. Krinn DNZ (talk) 05:17, 11 May 2024 (UTC)

Addendum: I think the most appropriate comparison here is KFC — both in the sense of, the IP holder can't decide what it means by fiat, and in the sense of, Wikipedia correctly explains the history of the term. That article would be materially worse if it removed all reference to "Kentucky Fried Chicken", right? So we should do similarly here: acknowledge the roots of the name and not participate in an ill-advised attempt to erase meaning. Krinn DNZ (talk) 08:41, 11 May 2024 (UTC)

Also see the naming section with some more explanation. The term 'extended Berkeley Packet Filter' is very misleading given it may lead to people think it's only about packet filters which it is not these days. Hence, eBPF only used as pseudo-acronym. Like git, llvm or other technology names. Jasonbar3121 (talk) 12:21, 31 May 2023 (UTC)

(See also IETF BPF charter description https://datatracker.ietf.org/doc/charter-ietf-bpf/) Jasonbar3121 (talk) 14:35, 1 June 2023 (UTC)

Neither of those examples supports omitting the historical explanation from this article. Git is in practice never treated as an acronym/initialism — among its users and creators, referring to it as "GIT" in all-caps is considered strange and abnormal. In addition, the idea that it's an initialism was from the beginning considered as one of multiple equally-valid options. By contrast, BPF is and was a coherent initialism that evolved into something else (due to the project stewards' unwise decision to go with "eBPF" instead of something that expressed a clean break). Meantime LLVM is an example that supports my point, rather than supporting the idea that we should delete the acronym explanation: the lede of that article currently says "LLVM originally stood for Low Level Virtual Machine, though the project has expanded and the name is no longer officially an initialism." and I think that's a great example for how we should do with this article. Krinn DNZ (talk) 23:38, 11 May 2024 (UTC)