Linux

The subject is considerably more complex and nuanced than expressed by these one or two (obviously frustrated) people. I won't presume to capture all the issues, but this person on HN does a decent job of capturing some of them:

You have a minority who wants to impose a change, and the concerns outlined in that video by the audience member reflects genuine concerns from many other maintainers and contributors.

That this discussion repeats itself can only be taken to be either:

1. Evil C programmers are stodgy and old, and can't/won't get with the program, boo!

2. The Rust minority has, as of yet, failed to properly answer what happens when C APIs change in either signature or semantics, either of which can break the Rust bindings. Some questions:

• Who tests to avoid this?

• Who's expected to fix it? The one changing the C code, who might not know Rust or a separate bindings team?

• Is there a process ? A person to contact/raise the issue with? To get help or to have the work done?

• What happens if the bindings cannot be fixed in time for the next Kernel release? Put differently, will Rust bindings changes hold back changes to the C code?

If broken bindings indeed can hold back changes, then C changes are held back by Rust and indeed then the onus is on the committer to either forego improving/evolving the C API or pick up Rust and fix the bindings also. In that case, yes, the Rust bindings will either freeze the C API or force the individual contributor to learn Rust.

That people repeat their concerns isn't an expression of stupidity any more than a result of the people driving Rust into the kernel have yet to properly communicate how they envision this process to work, I suppose.

And then there is this angle, which also exists:

The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.

In the spirit of making suggestions, as this frustrated Rust developer was doing, and in the spirit of reducing vulnerabilities, as Rust itself is trying to do:

Screen shots on lemmy are mostly hosted on remote sites, so they don't show up for people who block off-site media (e.g. to avoid tracking). They don't work with screen readers (e.g. for the vision impaired). They don't work with search at all.

And since Mastodon won't show anything unless the visitor allows javascript, and since it's a distributed platform instead of a single well-known site, a would-be visitor would have to allow javascript on random web sites in order to view Mastodon posts. That would expose them to tracking and browser exploits.

For these reasons, quoting the text you want to share would be better than screen shots or Mastodon links, for convenience, utility, and safety.

Full text of the post by Asahi Lina (@[email protected]):

I regretfully completely understand Wedson's frustrations.

A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away.

When I tried to upstream the DRM abstractions last year, that all was blocked on basic support for the concept of a "Device" in Rust. Even just a stub wrapper for struct device would be enough.

That simple concept only recently finally got merged, over one year later.

When I wrote the DRM scheduler abstractions, I ran into many memory safety issues caused by bad design of the underlying C code. The lifetime requirements were undocumented and boiled down to "design your driver like amdgpu to make it work, or else".

My driver is not like amdgpu, it fundamentally can't work the same way. When I tried to upstream minor fixes to the C code to make the behavior more robust and the lifetime requirements sensible, the maintainer blocked it and said I should just do "what other drivers do".

Even when I pointed out that other C drivers also triggered the same bugs because the API is just bad and unintuitive and there are many secret hidden lifetime requirements, he wouldn't budge.

One C driver works, so Rust drivers must work the same way.

Making the Rust bindings safe would have required duplicating much of the functionality of the C code just to track things to uphold the lifetime requirements. It made no sense. It would have been easier to just rewrite the whole thing in Rust (I might end up doing that).

To this day, bugs in the DRM scheduler have been the only causes of kernel panics triggered via my Apple GPU driver in production.

The design of that component is just bad. But because I come from the Rust world, the maintainer didn't want to listen to my suggestions.

If it takes a whole year to get a concept as simple as a trivial "device" wrapper upstreamed (not any device model functionality, literally just an object wrapping a struct device so we can pass it around) then how is Rust for Linux ever going to take off?

Rust works. I'm pretty sure I'm the only person ever to single handedly write a complex GPU kernel driver that has never had a memory safety kernel panic bug (itself) in production, running on thousands of users' systems for 1.5 years now.

Because I wrote it in Rust.

But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more. They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better.

There are some situations where I can see Rust's type-ststem potentially being counterproductive. For instance, it may be valid to invert lock order in a chain of operations under some circumstances, and rust might prevent you from expressing that. I grew up with C (from the pre-ANSI days) and while lifetimes and ownership are things that good C devs care about, they are tacit - and the ability to play fast and loose when necessary is great.

The linux kernel is built on a foundation of these implicit semantics. Some of it is written down, some of it isn't. I can see why asking "but what does this mean?" can lead to frustrating conversations and overly-qualified answers, but not everyone in that video was hostile to the prospect.

Based C devs.

The rust road WILL be built, the rust hotel WILL be built, and fuck whoever the land belonged to and all the previous infrastructure. They'll simply replace everything with Rust™ built infrastructure.

Rust wants to force itself into everything and to change everything it needs to get itself working, and for some reason it has a cult defending all of its moves to make everything Rust™ compatible.

This shit is getting ridiculous.