5 ms·

Ah, that sounds like a pretty serious limitation. Do you think they might relax this restriction in the future? In the talk, he mentions adding higher-level co

Ah, that sounds like a pretty serious limitation. Do you think they might relax this restriction in the future? In the talk, he mentions adding higher-level constructs to C like lists and RB-trees that are also concurrently-safe(!!) which seem just massive to me. It'd be stellar to be able to program in a safe C subset with some higher-level affordance like this.

tptacek 4y ago
I think they'll make incremental progress at accepting more programs, but that BPF-C programs aren't going to look like normal C programs any time in the near future. There's a bunch of data structures available to BPF programs, because they can call "helpers", which are just ordinary C functions. There are concurrent semi-durable key-value stores of varying types (eBPF "maps"). These aren't written in BPF-C; they're just kernel code that BPF gets to call. Adding new helpers is not nontrivial; you can't just load them into your kernel and call them; they're part of the kernel API.
brancz 4y ago
Having worked with eBPF for a while now, it’s actually interesting how it makes you think about useful limits, that we typically defer thinking about. For example instead of writing code that validates a string and then doesn’t care about the length anymore we just always limit it to only process a certain length in the first place. I’ve found few problems that I couldn’t find useful limits for. That’s not to say that the verifier isn’t limiting and at time difficult to deal with, but I find it less of a limitation in practice than it seems at first. Much like rust’s borrow checker I do think it takes a change in mindset. //edit Turns out being thoughtful about this when writing the code is also helpful for performance reasons as things like loops can be unrolled which can have significant performance gains.

tptacek 4y ago

I think they'll make incremental progress at accepting more programs, but that BPF-C programs aren't going to look like normal C programs any time in the near future. There's a bunch of data structures available to BPF programs, because they can call "helpers", which are just ordinary C functions. There are concurrent semi-durable key-value stores of varying types (eBPF "maps"). These aren't written in BPF-C; they're just kernel code that BPF gets to call. Adding new helpers is not nontrivial; you can't just load them into your kernel and call them; they're part of the kernel API.

brancz 4y ago

Having worked with eBPF for a while now, it’s actually interesting how it makes you think about useful limits, that we typically defer thinking about. For example instead of writing code that validates a string and then doesn’t care about the length anymore we just always limit it to only process a certain length in the first place. I’ve found few problems that I couldn’t find useful limits for. That’s not to say that the verifier isn’t limiting and at time difficult to deal with, but I find it less of a limitation in practice than it seems at first. Much like rust’s borrow checker I do think it takes a change in mindset. //edit Turns out being thoughtful about this when writing the code is also helpful for performance reasons as things like loops can be unrolled which can have significant performance gains.