Is it possible to write device drivers in eBPF? (I've asked this before, but haven't gotten any response, and no clear answer from Google/DDG either).
[deleted]
eBPF Is Awesome
31–40 of 46 posts
Re: eBPF Is Awesome
#32Earlier quoted context omitted.
I think dtrace has the same problem, i.e. it's pretty tightly coupled to the exact functions / trace points in the kernel. A different kernel can break a dtrace script, although I think their code changes a lot less than Linux does. It seems somewhat unavoidable, if the goal is to introspect the kernel at a very intimate level ...
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
Off topic, but thanks for being so inspiring ;)
Re: eBPF Is Awesome
#33What 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?
eBPF helps with kernel observability - an area that has been sorely lacking in the past. For the JVM or .NET, they give you virtually no insight at all into system calls - so eBPF is complementary to VM profilers, not a replacement. If you ever used Shark on OS X you will get a sense of how cool this is - this was a profiler for the OS X JVM which profiled the system calls as well and combined it all into a single trace tree. Maybe one day we'll get similar profilers on Linux for these systems - with eBPF it should be fairly straightforward.
OpenTelemetry is just a reference API. You could export metrics using eBPF as well. I'm pretty sure Sysdig does this for example.
Re: eBPF Is Awesome
#34Is it possible to write device drivers in eBPF? (I've asked this before, but haven't gotten any response, and no clear answer from Google/DDG either).
eBPF isn't Turing complete after being verified so I would assume no.
Re: eBPF Is Awesome
#35What 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?
eBPF helps with kernel observability - an area that has been sorely lacking in the past. For the JVM or .NET, they give you virtually no insight at all into system calls - so eBPF is complementary to VM profilers, not a replacement. If you ever used Shark on OS X you will get a sense of how cool this is - this was a profiler for the OS X JVM which profiled the system calls as well and combined it all into a single tr…
See Brendan Gregg's excellent work in this space
http://www.brendangregg.com/blog/2014-06-12/java-flame-graph...
Re: eBPF Is Awesome
#36Earlier quoted context omitted.
Technically it's JITted not AOT compiled.
The line is blurry. JIT compilation means compiling code on the fly right when you're about to execute it. When the code is part of a larger program, jitting allows to compile the parts of it you actually need and avoid wasting time to compile other parts. It also allows to compile the relevant code paths based on dynamic flow analysis, which often involves interpreting your program the first time you run it and emit…
What ithkuil said.
The time to translate the bytecodes is taken ahead of time, when the eBPF is installed, rather than the first time some other system call needs to actually execute the code.
It is not hard to imagine a system removing and installing eBPF bits dynamically according to realtime events, but it is a fair bet that in most uses they are set up at program start time and left in place.
Re: eBPF Is Awesome
#37> running a user space program inside the kernel
Isn't it actually running a user program in kernel space?
Re: eBPF Is Awesome
#38Is it possible to write device drivers in eBPF? (I've asked this before, but haven't gotten any response, and no clear answer from Google/DDG either).
eBPF isn't Turing complete after being verified so I would assume no.
Do device drivers typically need to be Turing complete? I would have expect drivers for simple USB devices for example to be pretty simple state machines.
Re: eBPF Is Awesome
#39Earlier quoted context omitted.
eBPF isn't Turing complete after being verified so I would assume no.
Do device drivers typically need to be Turing complete? I would have expect drivers for simple USB devices for example to be pretty simple state machines.
I'm not sure. Even if you could do it in eBPF, I really don't think you could get it past the verifier because it's not just like formal verification it actually has to be trivially bounded (so parts of it definitely could be done without Turing completeness but you ain't writing your GPU driver in it).
The JIT isn't necessarily turned on so it's probably not a great idea in the first place
Re: eBPF Is Awesome
#40Earlier quoted context omitted.
I think dtrace has the same problem, i.e. it's pretty tightly coupled to the exact functions / trace points in the kernel. A different kernel can break a dtrace script, although I think their code changes a lot less than Linux does. It seems somewhat unavoidable, if the goal is to introspect the kernel at a very intimate level ...
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 like this, for instance, though it would even further strengthen the language's concept of correctness if it did!)