I just happen to run into a freebsd video on dtrace (similar technology to eBPF, I think) that was created three weeks ago.
eBPF Is Awesome
41–46 of 46 posts
Re: eBPF Is Awesome
#42> The eBPF program is written in a pseudo-C code
Pseudo? This is a nit, but isn't it actually regular C?
Re: eBPF Is Awesome
#43I just happen to run into a freebsd video on dtrace (similar technology to eBPF, I think) that was created three weeks ago. https://www.youtube.com/watch?v=E06GVdH-LX0
I think comparing dtrace to eBPF is missing what makes eBPF great. dtrace is just one application that can be implemented using eBPF.
Your toolbox can be used to fix things, but eBPF is a factory for making new types of tools and toolboxes.
eBPF can be used to make small programs that run at tracing points, thus making dtrace. But it can also be made to make packet filter decisions (thus altering what happens), and with at least one network card that eBPF program can be pushed to the network card and filter before the packet even hits RAM, much less the CPU!
eBPF can run at socket init time, and set some default TCP tuning parameters.
Another comment in this thread asked if one can write a whole device driver in eBPF. The answer is actually not clear.
eBPF is more similar to "the ability to load kernel modules" than it is "a tracing framework".
Re: eBPF Is Awesome
#44Earlier quoted context omitted.
No, DTrace does not have this problem, though our solution to it is one of the least well known aspects of DTrace: we have a notion of explicit stability that allows for stable scripts to be built on top of very low level implementation details that themselves might change. See the chapter on "Stability" in the Dynamic Tracing Guide[1] for details. [1] http://dtrace.org/guide/chp-stab.html
> Stability attributes are computed for most D language statements by taking the minimum stability and class of the entities in the statement. That's a fascinating read and an amazing idea. To your knowledge are there any other software ecosystems that track stability in nearly as formalized a way? Has there been investigation into bringing these ideas into other modern languages? (I don't believe Rust has a concept…
Well, we certainly thought it was a big deal! We were really trying to address this issue of writing stable scripts -- allowing for stable, powerful tooling without ossifying the underlying system. I'm really pleased with the work we did there -- but it's unquestionably one of the more esoteric aspects of DTrace.
Something of a funny story that this brings to mind: the taxonomy we have here is actually the interface taxonomy from what was Sun's Platform Software Architecture Review Committee (PSARC), which itself borrowed it from Sun's larger Software Development Framework (SDF). We had to get DTrace reviewed by PSARC, which we weren't necessarily looking forward to -- in part because of big developments like this one. To get past our PSARC review, we adopted several strategies, one of which was to separate out DTrace from its instrumentation providers as separate cases before the committee. When we first presented DTrace to PSARC, committee members wanted to fixate on instrumentation methodology -- and it was very helpful to be able to defer these fixations to later cases (after having let members pontificate and chew up some of the clock, of course). The other technique that we developed (which was devastatingly effective) was to distract the committee with issues that were irrelevant but amenable to debate. When a debate emerged among the committee members (and PSARC being more or less a debating society, this was practically guaranteed), we would effectively feed both sides of the debate -- and in the end, run out the clock on something we didn't care about. All of this worked exceedingly well -- and DTrace itself (one of the largest cases that had ever appeared before PSARC) was approved with essentially no modifications.
Shortly after the DTrace case was approved, we started bringing forward cases on instrumentation providers. With each case, we presented the stability matrix of that particular provider; on the first such case, I remember vividly one committee member asking: "what the hell is this and when do we review it?!" We explained that it was the stability matrix -- as explained at length in the case that they had in fact already approved. They realized in an instant that they had fixated on a dinghy of nomenclature while we had slipped behind them an ocean liner of semantics -- and it was glorious.
Re: eBPF Is Awesome
#45Earlier quoted context omitted.
> Stability attributes are computed for most D language statements by taking the minimum stability and class of the entities in the statement. That's a fascinating read and an amazing idea. To your knowledge are there any other software ecosystems that track stability in nearly as formalized a way? Has there been investigation into bringing these ideas into other modern languages? (I don't believe Rust has a concept…
Well, we certainly thought it was a big deal! We were really trying to address this issue of writing stable scripts -- allowing for stable, powerful tooling without ossifying the underlying system. I'm really pleased with the work we did there -- but it's unquestionably one of the more esoteric aspects of DTrace. Something of a funny story that this brings to mind: the taxonomy we have here is actually the interface…
> The other technique that we developed (which was devastatingly effective) was to distract the committee with issues that were irrelevant but amenable to debate.
It's not exactly the same but this reminds me of the way Matt Stone described his interactions with the MPAA board in This Film Is Not Yet Rated (https://en.wikipedia.org/wiki/This_Film_Is_Not_Yet_Rated).
i.e. they went into the Team America rating negotiation with aggressive material they were prepared to cut, and probably wanted to cut anyway, and let the committee spend all their time on that.
See also (NSFW):
https://youtu.be/SgyG8y1vg1M?t=151
https://lettersofnote.com/2009/09/30/p-s-this-is-my-favorite...
Re: eBPF Is Awesome
#46What are the benefits of using eBPF besides a promise of observability "for free"? Can eBPF be used for observability using platforms like Java or .net core, or does their platform VMs obfuscate too much and monitoring them using eBPF is not feasible? How does eBPF work wrt OpenTelemetry etc.? Should OpenTelemetry be seen as standardized interfaces to which eBPF reports data?
It’s definitely possible in some VMs. I’ve been working in a Ruby profiler that collects the stacks from a BPF program [1]. There are some BPF safety mechanisms that require some creativity to overcome such as max instructions, not being Turing complete, etc.