Long time “old-school” kernel maintainers don’t know Rust and don’t want to learn Rust (completely fair and reasonable). But some of them don’t want to work with the Rust guys for lots’o’technical reasons.
It’s by far not an easy situation technically. Like this is a huge challenge.
But some of those old-school C guys are being vocal about their dislike of Rust in the kernel and gatekeeping the process. This came to a head at a recent conference (Linux Plumbers Conference?) and now one of the Rust maintainers has quit.
The big technical challenge is being confounded by professional opinions.
Yea, so mainly one situation that isn’t explained here. Is that the moment you introduce a different language besides C, you now need to talk between C and this other language. This is called language bindings.
The problem with this, is the moment something is changing in C, and this method or interface is used by some Rust code, the Rust binding to C or C to Rust binding is failing, cause all kinds of issues.
Long story short, is that by introducing this additional language you created this technical issue of language bindings. And people who just want to work with C code, now suddenly also need to think about Rust bindings, while they previously didn’t need to think about that. As if the Linux kernel isn’t complicated enough, introducing this language binding issue is cause more (unwanted) work for some people.
In the end the “C” people are blaming Rust if something fails. And the “Rust” people are trying to explain and help the “C” people to introduce those bindings. waaaahhhh
It’s not about the bindings. It’s, as always with kernel devs, about gatekeeping and unprofessional if not outwardly hostile behavior.
Maintaining bindings is a hard problem for sure, but no hard problems have ever been solved by the key stakeholders refusing to partake in honest discussions. Asahi Lina’s breakdown of her rejected contributions to the fundamentally flawed drm_sched, which do not involve a single byte of Rust, demonstrates an unwillingness to collaborate that goes much further than the sealioning about muh bindings.
Long time “old-school” kernel maintainers don’t know Rust and don’t want to learn Rust (completely fair and reasonable). But some of them don’t want to work with the Rust guys for lots’o’technical reasons.
It’s by far not an easy situation technically. Like this is a huge challenge.
But some of those old-school C guys are being vocal about their dislike of Rust in the kernel and gatekeeping the process. This came to a head at a recent conference (Linux Plumbers Conference?) and now one of the Rust maintainers has quit.
The big technical challenge is being confounded by professional opinions.
Yea, so mainly one situation that isn’t explained here. Is that the moment you introduce a different language besides C, you now need to talk between C and this other language. This is called language bindings.
The problem with this, is the moment something is changing in C, and this method or interface is used by some Rust code, the Rust binding to C or C to Rust binding is failing, cause all kinds of issues.
Long story short, is that by introducing this additional language you created this technical issue of language bindings. And people who just want to work with C code, now suddenly also need to think about Rust bindings, while they previously didn’t need to think about that. As if the Linux kernel isn’t complicated enough, introducing this language binding issue is cause more (unwanted) work for some people.
In the end the “C” people are blaming Rust if something fails. And the “Rust” people are trying to explain and help the “C” people to introduce those bindings. waaaahhhh
It’s not about the bindings. It’s, as always with kernel devs, about gatekeeping and unprofessional if not outwardly hostile behavior.
Maintaining bindings is a hard problem for sure, but no hard problems have ever been solved by the key stakeholders refusing to partake in honest discussions. Asahi Lina’s breakdown of her rejected contributions to the fundamentally flawed
drm_sched, which do not involve a single byte of Rust, demonstrates an unwillingness to collaborate that goes much further than the sealioning about muh bindings.