Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Write your BPF programs in Go, not C

github.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Show HN: Write your BPF programs in Go, not C

#41

Post by rounce »

auxiliarymoose wrote: post #18
hnlmorg wrote: post #15

Earlier quoted context omitted.

But again, this isn't intended for a general audience. Anyone who might need this would already know what BPF is. And anyone who isn't familiar with the term BPF in this context wouldn't be the target audience for this. It's also worth noting that BPF isn't ever referred to in it's non-acronym form. Literally no-one in the field calls this "Berkeley Packet Filter". Just like nobody calls PHP "PHP: Hypertext Processor…

Well, it's posted on Hacker News which is a general audience including people working on electrical/signal/audio/radio-frequency systems among other things (not just low-level network code) where BPF has a different meaning, so I think disambiguation is appropriate.

Nitpick: eBPFs aren’t just for low level networking manipulations but also lots of other parts of the kernel. In fact the expanded version of the acronym is slightly confusing as it sort of implies being entirely to do with networking, which it isn’t.

Re: Show HN: Write your BPF programs in Go, not C

#43

Post by vetrom »

hnlmorg wrote: post #22

> Why transpile, not generate BPF directly > gc, the Go compiler, has no LLVM-based BPF backend. Adding one is a multi-year compiler project. rustc is built on LLVM and that's why Aya works. So gobee emits C and reuses clang's BPF backend, which gives us mature codegen, BTF, and CO-RE relocations for free. I wonder if TinyGo ( https://tinygo.org/ ) might be a better fit here: > TinyGo brings the Go programming langua…

Well tinygo takes some go bindings they implemented for llvm, https://github.com/tinygo-org/go-llvm, uses the Go standard library for parsing, and wires it up to a LLVM IR generator, with a set of flexible backend/machine definition machinery.

You could likely improve gobee to use tinygo's packages directly, instead of transpiling to C and calling into clang, and the licenses of the two projects look compatible. You'll still need to deal with defining a subset to pass the verifier, of course.

---

From the README:

> Replace clang. clang's BPF backend gives us CO-RE, BTF, and verifier-friendly codegen for free. Reimplementing that costs years and gains nothing.

The primary gotcha you may hit if you try this is how much of the BPF features are implemented by clang, and how much is instead implemented in core LLVM. Even with a LLVM sitting next door you could pull out, the harnesses may not exist independent of clang, but I have not looked THAT deep.

Re: Show HN: Write your BPF programs in Go, not C

#46

Post by poly2it »

Fun fact: naming identifiers with leading underscores in C conflicts with reserved use and should always be avoided. I noticed Gobee declares double-underscores liberally.

Per 6.4.3 (Identifiers) of C23 (ISO/IEC 9899:202y N3886):

  — All identifiers that begin with a double underscore (__) or begin with an underscore (_) followed by an uppercase letter are reserved for any use, except those identifiers which are lexically identical to keywords.
  — All identifiers that begin with an underscore are reserved for use as identifiers with file scope in both the ordinary and tag name spaces.
https://open-std.org/JTC1/SC22/WG14/www/docs/n3886.pdf

And per 7.1.3 (Reserved identifiers) of C11 (ISO/IEC 9899:201x N1570):

  — All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Re: Show HN: Write your BPF programs in Go, not C

#48

Post by beanjuiceII »

atgreen wrote: post #31
hnlmorg wrote: post #22

> Why transpile, not generate BPF directly > gc, the Go compiler, has no LLVM-based BPF backend. Adding one is a multi-year compiler project. rustc is built on LLVM and that's why Aya works. So gobee emits C and reuses clang's BPF backend, which gives us mature codegen, BTF, and CO-RE relocations for free. I wonder if TinyGo ( https://tinygo.org/ ) might be a better fit here: > TinyGo brings the Go programming langua…

Here's another option.. I created an optimizing eBPF compiler in Common Lisp for a lisp-ish DSL. It's nice because you can compile and load your eBPF code all in-process in lisp (even from your REPL) without any external tooling. https://github.com/atgreen/Whistler

[flagged]

Re: Show HN: Write your BPF programs in Go, not C

#49

Post by dwattttt »

7373737373 wrote: post #42

Noob question: why did they not choose to use WebAssembly in the kernel instead?

eBPF predates WebAssembly by a few years. I'm also not sure Linux would've wanted to integrate and rely so heavily on a standard they aren't in control of the design of.

Re: Show HN: Write your BPF programs in Go, not C

#50

Post by dwattttt »

aeonik wrote: post #9
auxiliarymoose wrote: post #8

Earlier quoted context omitted.

I'm guessing Berkeley Packet Filter: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter This is why National Aeronautics & Space Administration (NASA) guidance is the following: > Acronyms often confuse readers. Avoid them whenever possible. If an acronym is necessary for future reference, spell the full word and follow with the acronym in parentheses on the first reference. For example, The General Services Admini…

To be honest BPF is one of those acronyms that I think might be more recognizable as the acronym than what it actually stands for. Not quite as much as Radar or Laser, but halfway there.

And today I learned this has a name, anacronym! An acronym that has become so common, it's treated as a word instead of an acronym.
Post reply on HN