Comment by gpm
10 months ago
I think you're discounting the very real damage that would be done by Linux a project controlled by Linus and a community being replaced by Linux a project controlled by Google/Samsung/Redhat/Microsoft. I'm afraid that this is what is going to happen with the Linus tree effectively rejecting rust drivers by subjecting anyone attempting to upstream rust code to persistent bullying, but I don't want it to happen.
> I think you're discounting the very real damage that would be done by [Linux a project controlled by Linus and a community] being replaced by [Linux a project controlled by Google/Samsung/Redhat/Microsoft.]
(Brackets added for clarity)
Isn't the current Linux already Linus + communities + companies?
More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
> Isn't the current Linux already Linus + communities + companies?
Absolutely. To that point the companies I listed are the ones that I'm aware of employing kernel developers who work specifically on rust in linux.
The control of the project is in Linus's/community hands though, not corporate ones, and I think that's a good thing.
> More to the point, any two such projects would quickly diverge. Once a particular piece of Linux is reimplemented in Rust, if the C version adds a feature it is no longer as simple as applying a patch to keep in sync.
I don't think so. Linux is a huge modular system, and no one is really interested in rewriting the core components of it at this point. Nor maintaining their own copies of components that some other company is responsible for (like graphics drivers). Until and unless it became the dominant fork I'd expect that they'd keep merging in the mainline branch and updating their things as necessary.
This is already how projects like Android work.
> subject upstream rust code to persistent bullying
I don’t remember seeing this bullying accusation in your original comment. Was it edited in?
Regardless, the “bullying” happened on both sides. Hector Martin started the social media brigading and quit when he couldn’t get his personal enemy suspended for CoC violations. Jonathan Corbet wrote a letter naming and shaming maintainers, in the guise of a report.
All in all, I agree with the GP. Most of the arguments against (even temporary) forking feel like excuses for a lack of will and a maybe even a lack of ability. The space is open for a fork.
I may have edited the phrasing within a minute or two of posting, couldn't say. I haven't edited the comment in the 14 hours since then, and the sentiment was in the original.
(I have edited this comment on the other hand, first to explicitly disagree with various statements in the above, then to delete those disagreements since I don't really want to get baited into an argument)
Why do people think rejecting rust drivers is a bad thing? It's a fucking c project.
Does Linux have the ability to load drivers dynamically (like Windows)? Is there a reason why developers don't develop drivers outside of the kernel and have users simply install them post-install?
Yes, it technically does (kernel modules), but the difference between Linux and NT is that Microsoft guarantees (as much as possible) that its ABIs are stable whereas Linux explicitly does not preserve backwards compatibility in the kernel (only the userspace is the stable interface).
EDIT: Reading this: https://www.kernel.org/doc/Documentation/process/stable-api-...
It seems like a huge technical factor holding back a stable ABI is the C compiler itself. Binaries changing between compiler versions and changing with different compiler flags.
So while your code can be written such that it appears to respect the interface of an external library, the underlying binary representation might not line up correctly.
If there is agreement that modularity is good for the kernel but technical limitations prevent that from being a reality - surely the solution is to improve C's interoperability first?
---
I'm not a kernel developer and am probably naive here, but on the surface it feels like offering a stable driver ABI is one possible solution to the rust-in-linux controversy that has lead to so many people exiting kernel development.
I'd imagine if projects like Asahi could simply offer out-of-tree drivers, they wouldn't need to maintain a kernel fork (at least not for drivers) or negotiate with core maintainers (which I understand is stressful).
Might also make it easier for vendors like Qualcomm/Samsung/Nvidia to distribute drivers out-of-tree, perhaps reducing the need for long running Linux forks and allowing devices to update to modern Linux kernels.
As a novice hacker, I'd imagine the ability to reuse proprietary driver blobs would allow distros to be created targeting hardware that was otherwise impossible to access as drivers were hidden behind custom kernel forks (e.g. install mainline Fedora on a Samsung phone, taking the GPU driver from the Samsung build of Android - or OpenWRT on an Android powered portable 5g modem).
2 replies →
It can, but Linux does not have a stable driver ABI. Whoever wrote the out-of-tree drivers would have to constantly update them whenever there was a breaking change to the kernel, which I understand is relatively common.
That's interesting. Dumb question but why doesn't Linux aim for a stable driver ABI? Does it impede delivery speed?
I think nvidia uses out-of-tree drivers that are dynamically loaded - does that mean that nvidia drivers are tied to specific kernel versions?
3 replies →
Yes, it can load drivers dynamically.
There is a reason why in-tree drivers are preferred, and that's because the Linux driver interface and API changes with kernel API changes. The API is considered unstable in the sense that is it not unchanging.
A driver written for one release of Linux may not work with the next release as the API changes.
To my knowledge, out-of-tree drivers are quite inconvenient to maintain compared to in-tree drivers, due to the kernel's unstable API (a driver that works on a given version of the kernel likely only works on that single version unless it has lots of ifdefs to handle all the other versions).
> controlled by Google/Samsung/Redhat/Microsoft.
Can they do that to openssl instead?
Thank you.
They did: https://github.com/aws/aws-lc / https://github.com/google/boringssl
(Not in rust, but it's mostly assembly anyways so I'm not sure rust provides much. There is https://github.com/briansmith/ring in rust, not sure if it's sponsored by anyone)
[flagged]