* Posts by bgregg

4 publicly visible posts • joined 11 Jun 2015

Linux kernel's eBPF feature put to unexpected new uses

bgregg

Re: Why is this thing named after the BPF?

I think the real answer why it's called BPF or eBPF is that it's a technology created by a bunch of kernel engineers with no involvement from professional tech marketing, who would have given it a better name long ago. I'm not a marketing professional, but sure, it would be better called the "Kernel Execution Environment" (KEE). Wait, it can be user space too. How about the "BPF Execution Environment" or BEE for short. We already have a bee as the mascot! And the "BPF" part is a name and not an acronym. I'm joking as what it really needs not a kernel engineer to come up with a better name. :-)

It does come from BPF, which was implemented using a VM. eBPF extended it.

What's your source about it being designed and built with Lennart? I've been involved in eBPF from the beginning (2014) and have not run into him regarding BPF at all. However, I'm sure by now (2022) he's commented on it, since it's taking over Linux and everyone has run into it by now.

Microsoft embraces Linux kernel's eBPF super-tool, extends it for Windows

bgregg

Re: hope I'm missing something here

1) I'm a major BPF contributor (tracing) and have worked on eBPF since 2014, and Lennart's name hasn't come up. I don't know where you're getting your information from.

2) BPF is a generic sandbox. Like JavaScript. Hence presenting an instruction set. Don't worry, it gets compiled into machine code, so it isn't slow. It provides a way to build kernel solutions that are safe for people to run (and many already are, in production). In simple terms: if you're a Windows user, it's the difference between downloading and running a .exe vs visiting a website with JavaScript. Huge difference, right?

Microsoft to Linux users: Explain yourself

bgregg

Not another sar clone

The list of metrics is useful, but not novel (mostly the standard sar stuff, with a few extra guest metrics), and certainly not what I'd call pain points. Pain points include making the Linux tracers easier to use by a wider population (eg, the built-in ftrace & perf_events, the currently-being-integrated eBPF, and all the other add-ons like SystemTap and LTTng). These fall more into analysis than monitoring, but a good tool will do both.