Whistler: Live eBPF Programming from the Common Lisp REPL

Just recently discovered the author, Anthony Green. Floored and inspired by his productivity and scope of projects!

I enjoyed reading up on his fiber implementation and dabbling with the Java compiler/runtime integration.

https://atgreen.github.io/repl-yell/posts/sbcl-fibers/

https://github.com/atgreen/openldk

Kudos Anthony - you make the world a more interesting place ;-)

What makes eBPF particularly well-suited for REPL-style development is the verifier. Every BPF program gets statically verified by the kernel before it runs -- no unbounded loops, no out-of-bounds memory access, no null dereferences. That safety guarantee is what makes "live" iteration safe: you can't panic the kernel, you just get a rejection and iterate. It's the closest thing to a systems-level sandbox that doesn't require a VM.

The interesting design space here is the feedback loop. bpftrace already gives you ad-hoc one-liners for tracing, but it's a separate language you have to context-switch into. Running eBPF programs directly from a Lisp REPL where you already have your analysis code means the kernel tracing and the result processing live in the same environment. You can define a probe, collect data, and immediately run your existing Lisp functions over it without serialization or context switching between tools.

The catch is that the verifier imposes constraints that don't map cleanly to Lisp's programming model -- no recursion, stack limit of 512 bytes, bounded loops only. Bridging that mismatch at the macro level seems like the harder problem than the basic REPL integration.

This is very cool.

I'm in danger of being nerd sniped.

While this is an interesting project, I found following grating:

"Permissions without root

You don’t need root. Grant capabilities to SBCL:

sudo setcap cap_bpf,cap_perfmon+ep /usr/bin/sbcl

Now sbcl --load my-bpf-program.lisp works as your regular user. Tracepoint format files need chmod a+r to allow non-root compilation with deftracepoint."

That's obviously not ideal. Better might be to create a purpose-built image. Unlike perl, sbcl doesn't even pretend to care about security. Taint mode extension for sbcl, anybody?

Very impressive, good reason to get into Lisp, I reckon

very cool and the person has the skills to do that. sad to see how the fully AI generated "why this matters" section in the blog gives a lingering vibe of slop.