I regretfully completely understand Wedson's frustrations.
https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@gmail.com/
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.
It is a project! All games are, 😅, just follow the instructions from the README. You’ll be solving Rust exercises on your preferred editor, and get some feedback from a terminal window. It’s great.
It is a project! All games are, 😅, just follow the instructions from the README. You’ll be solving Rust exercises on your preferred editor, and get some feedback from a terminal window. It’s great.
Welp, that means I set up my neovim with rust as well… will do when I got time!