Rust Linux Developers Compared To Road Builders & Mapmakers
Given the recent talk of a Linux Rust maintainer stepping down due to "nontechnical nonsense" and other Rust Linux kernel drama in recent days, Airlie wrote a blog post comparing the types of developers and how he feels they should better engage and work together.
"I think the [Rust for Linux] project has a had lot of excellent wayfinding done, has a lot of wayfinding in progress and probably has a bunch of future wayfinding to do. There are some nice hotels built. However now we need to build the roads to them so others can build hotels.
To the higher authority, the road building process can look slow. They may expect cars to be driving on the road already, and they see roadblocks from a different perspective. A roadblock might look smaller to them, but have a lot of fine details, or a large roadblock might be worked through quickly once it's engaged with.
For the wayfinders the process of interacting with maintainers is frustrating and slow, and they don't enjoy it as much as wayfinding, and because they still only care about the hotel at the end, when a maintainer gets into the details of their particular intersection they don't want to do anything but go stay in their hotel."
Read the post in full on Airlie's blog.
This also comes as Asahi Linux developer Asahi Lina wrote a Mastodon post criticizing the headaches involved in upstreaming Rust code for the Linux kernel and the friction that often takes place with kernel maintainers:
"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."
Unfortunately, there is no easy solution.
136 Comments
