Aya Makes It Easy To Write Rust-Based eBPF Programs For The Linux Kernel

[uid313]

And there's your mistake. Don't try to bind the language to your will, try to learn how to work with what it offers. It's painful and it requires unlearning stuff you already know, but it's the only way to learn a ne language properly. God knows I've made that mistake before and I still can't do it naturally.

I've learn lots of new stuff with Rust and I like it, I learnt message passing over channels and Option as well as Result generic enums, and lots of other stuff. I enjoyed learning Rust, but I like to learn Rust and do things in idiomatic Rust instead of having to rely on workarounds.

[uid313]

While I don't see anything bad with writing Rust for eBPF, I think it offsets pretty much all of the major advantages of the language. You can't `malloc` in eBPF, you can't use (explicit) concurrency and the limitations imposed by the verifier pretty much make it so it's already safe; it's not like regular systems and programs where Rust shines. Plus, you might stumble across the instruction limit if the output ends up being large.

I don't know, Rust offers a lot more than just memory safety and concurrency, it also provides very nice things such as Option<T> and Result<T> generic enum types, as well as pattern matching, traits, etc.

[NobodyXu]

I've learn lots of new stuff with Rust and I like it, I learnt message passing over channels and Option as well as Result generic enums, and lots of other stuff. I enjoyed learning Rust, but I like to learn Rust and do things in idiomatic Rust instead of having to rely on workarounds.

It’s not just a workaround to use boxer dyn Future for async function in trait, it’s a common practice in Rust projects and in other languages as well.

[CommunityMember]

While I don't see anything bad with writing Rust for eBPF, I think it offsets pretty much all of the major advantages of the language.

You seem to be missing an important advantage (especially moving forward) that some people and organizations will know/understand Rust (well), and not some other language. Most things one can write in Python one could write in native assembler, too, but many individuals and orgs have real depth in only a few language domains, and they prefer to use what they know (well) and it is the job of the compiler(s) is to make it all work (well).

[sinepgib]

You seem to be missing an important advantage (especially moving forward) that some people and organizations will know/understand Rust (well), and not some other language. Most things one can write in Python one could write in native assembler, too, but many individuals and orgs have real depth in only a few language domains, and they prefer to use what they know (well) and it is the job of the compiler(s) is to make it all work (well).

For that low level of abstraction C is pretty much the lingua franca, so if it is for being well known, I expect more people to be familiar with C than with Rust. In any case, I wouldn't trust anything that runs at kernel level that's written by someone who can't write C (which doesn't mean the code itself need to be written in C).

[RahulSundaram]

For that low level of abstraction C is pretty much the lingua franca, so if it is for being well known, I expect more people to be familiar with C than with Rust. In any case, I wouldn't trust anything that runs at kernel level that's written by someone who can't write C (which doesn't mean the code itself need to be written in C).

Plenty of kernels already exist in other languages including C++ and Rust. In the past knowledge of C was useful and this is no longer strictly the case. This is part of the reason ebpf is popular. It allows you to make changes dynamically using Rust or bpftrace.

[sinepgib]

Plenty of kernels already exist in other languages including C++ and Rust. In the past knowledge of C was useful and this is no longer strictly the case. This is part of the reason ebpf is popular. It allows you to make changes dynamically using Rust or bpftrace.

There's exactly zero arguments against my claim here. All of those people who wrote kernels in C++ and Rust are perfectly capable of writing C. They chose not to because those languages are either safer, more ergonomic, or both. But if you _can't_ write C you _can't_ think in low level either, so you better stay away from low level problems.
As the comment you quoted says, it isn't about the output being C, but about the ability to write it. Most of what makes C complicated is understanding machine level issues, and you definitely need that here.
Also, even tho those systems exist, mainstream OSes are either fully or partially C so, again, if you had any exposure to low level stuff you've been exposed to C. That's why it's the lingua franca.

[ssokolow]

There's exactly zero arguments against my claim here. All of those people who wrote kernels in C++ and Rust are perfectly capable of writing C. They chose not to because those languages are either safer, more ergonomic, or both. But if you _can't_ write C you _can't_ think in low level either, so you better stay away from low level problems.
As the comment you quoted says, it isn't about the output being C, but about the ability to write it. Most of what makes C complicated is understanding machine level issues, and you definitely need that here.
Also, even tho those systems exist, mainstream OSes are either fully or partially C so, again, if you had any exposure to low level stuff you've been exposed to C. That's why it's the lingua franca.

I'd argue that there's a difference between understanding the low-level semantics and being an effective C programmer and that difference is internalizing the big maze of "this is implementation defined behaviour" and "this is undefined behaviour" in the C spec that allows the compiler to [s]sabotage[/s] optimize your code in the name of performance.

It's entirely possible to understand the low-level stuff and be productive in Rust without knowing all that as long as someone else (either a more experienced team member or the author of a dependency) designs an API which encapsulates away the quirks of C that are exposed at the FFI boundary.

That's the whole point of having the unsafe keyword and the unsafe_code warning. (Put your unsafe code in a module only your senior developers are allowed to touch, put #![forbid(unsafe_code)] in the root of every other module, and you have a huge amount of power to prevent developers who haven't memorized the quirks of maintaining the relevant memory invariants from shooting themselves in the foot.

[NobodyXu]

For that low level of abstraction C is pretty much the lingua franca, so if it is for being well known, I expect more people to be familiar with C than with Rust. In any case, I wouldn't trust anything that runs at kernel level that's written by someone who can't write C (which doesn't mean the code itself need to be written in C).

BPF is different from C in that it doesn’t expose a turing complete machine and it forbiddens many memory related operations to be safe, thus it makes sense for people who aren’t C/machine/assembly experts to write them and run them inside kernel, safely.

Also, BPF can be generated by other tools, such as iptables or other system profilers, so it’s less likely to have low level bugs in there.

[sinepgib]

I'd argue that there's a difference between understanding the low-level semantics and being an effective C programmer and that difference is internalizing the big maze of "this is implementation defined behaviour" and "this is undefined behaviour" in the C spec that allows the compiler to [s]sabotage[/s] optimize your code in the name of performance.

It's entirely possible to understand the low-level stuff and be productive in Rust without knowing all that as long as someone else (either a more experienced team member or the author of a dependency) designs an API which encapsulates away the quirks of C that are exposed at the FFI boundary.

That's the whole point of having the unsafe keyword and the unsafe_code warning. (Put your unsafe code in a module only your senior developers are allowed to touch, put #![forbid(unsafe_code)] in the root of every other module, and you have a huge amount of power to prevent developers who haven't memorized the quirks of maintaining the relevant memory invariants from shooting themselves in the foot.

That's all nice in theory, but in reality if you've learned low level, you've coded C. That's the present situation.

BPF is different from C in that it doesn’t expose a turing complete machine and it forbiddens many memory related operations to be safe, thus it makes sense for people who aren’t C/machine/assembly experts to write them and run them inside kernel, safely.

One thing is security in terms of crashing your system. Indeed, BPF makes it safe in those terms. Now, poorly written BPF could lead to, e.g., all the packets in my system suddenly being dropped. But most importantly, pretty much all motivations to write BPF come from low level needs.
Let's say you're writing a packet filter. You need to understand binary protocols. You need to understand endianess. You need to understand buffer overflows. Even if the latter won't pass the verifier if it's wrong, good luck understanding why.
Lastly, I never mentioned being experts. I mentioned being able to write code properly. I can accept someone who'll fall prey to UB (everyone does one time or another). But someone who would be "unfamiliar"? I wouldn't believe they were exposed to anything low level. Not today, maybe someday, but right now Rust is young and pretty much every source to learn assumes you've done some C before.

Regarding the safety features of BPF, yes, exactly, and that's why I think Rust is not as valuable here as it generally is.

Also, BPF can be generated by other tools, such as iptables or other system profilers, so it’s less likely to have low level bugs in there.

iptables is a higher level interface. We're talking about manually writing BPF, not whether or not there are friendlier tools that use it.