On: A Beginner's Guide to eBPF

[tptacek]

It would be much easier to write a kernel module than an eBPF program. But the eBPF program is unlikely to panic your machine, and the kernel module is almost certain to.

[israrkhan → tptacek]

Also In cloud environments, I would much rather trust an eBPF program, than a kernel module.

[anonymousDan → israrkhan]

Why in cloud environments?

[Temporary_31337 → anonymousDan]

You don’t want kernel panic affecting other users

[cassianoleal → Temporary_31337]

Why would your cloud instance panicking affect other users of the cloud provider?

Or do you mean something else?

[bionsystem → cassianoleal]

Anecdotically, I had the case on VMWare 4 (that was in 2012 or 2013) that a Solaris 11 VM managed to reboot the entire ESX it was hosted on. Very weird bug where ESX passed through some interrupt or something.

But in this case I think they mean on the same machine. "In production" would be more accurate than "in a cloud environment". And yeah I wouldn't load custom kernel modules in production just to do observability.

[kqr → cassianoleal]

Cloud goes beyond rented VMs. Fully managed cloud services have thousands or millions of production customers on the same node. They have to be very careful about what they run as root.

[vocram → kqr]

I understand your point, but millions sounds an exaggeration- I have a hard time believing a single node can handle millions of concurrent users

[kqr → vocram]

I didn't mean to imply concurrent. A large fraction of the user base is very sporadic in its usage!

[vocram → kqr]

Thanks for clarifying :)