3 ms·
I personally think Linus is making the right choice here, and not explicitly denying Rust in the kernel. Instead he is delegating it to other high level maintai
by progmetaldev 2y ago
I personally think Linus is making the right choice here, and not explicitly denying Rust in the kernel. Instead he is delegating it to other high level maintainers to work out the issues and make the decisions on how the integration will go. He is already so heavily involved in day to day operations in the C code, I can't imagine him being able to take on the burden of also needing to negotiate pulling in an entirely new language.
From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code).
I am not for or against Rust being in the kernel, but I can appreciate the view of maintainers on a project of this age being concerned about introducing a second language (one which many of the C developers are not familiar with). This isn't a single company's web application project where a polyglot environment should work well when chosen for the right reasons. The Linux kernel is a backbone of modern computing, and making a decision on what to do without exploring all potential benefits and issues would be irresponsible at best. From what I've read, the Rust proponents want a piece of Rust middleware for DMA access so that each rust component doesn't need to have their own implementation, but the C maintainers don't wish to have to maintain C interface compatibility for Rust. With Linus stating that all code in the project must compile to be accepted in a release, this puts a heavy burden on the C maintainers where they are now required to work with the Rust developers fairly closely. Some of these maintainers have been around for a long time, and are skilled in C and do not wish to learn a new language for when the shit hits the fan and something in the Rust code breaks.
Again, this is just my understanding of the situation from what I've read, I may have some of this completely wrong, and if so I apologize to anyone involved.
- timeon 2y ago> From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code). This does not seems like arguing in a good faith. As example last 'drama' was explicitly about that PR with Rust code went into Rust branch not under C maintainer. Yet he blocked it anyway even when Rust maintainers stated, again, that any change in C API, that would break Rust code, was responsibility of Rust maintainers. Yet people (like you) are still ignoring this. Why?
- progmetaldev 2y agoPlease see this thread, which is where I got my information from. If you have a better source, I would love to read it. I understand that you may be passionate about wishing to have Rust in the kernel, but I was not fighting for or against this. To claim that I am not arguing in good faith (I am not arguing), and then to say that I am ignoring what you've said is the actual argument in bad faith. I also stated to correct me if I'm wrong, but I will believe this thread over a comment that seems to be more emotion over fact (as I fail to see how I ignored anything, and made no claim to be an expert). I would love an actual conversation over this, but only in actual good faith. Subject: Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction. https://lwn.net/ml/all/20250108135951.GA18074@lst.de/ https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
- steveklabnik 2y agoIf you read the patch, it puts no code in kernel/dma.
- progmetaldev 2y agoI probably didn't describe myself well enough. I was under the assumption that there was a Rust middleware to interface with the C API, and some of the C maintainers objected even to this because they feel they will need to be in communication with the Rust maintainer(s). I am not against Rust being used alongside, or even in the kernel. I was just pointing out some of the objections the C developers were stating. I believe there is a middle ground where everyone can be happy, and firmly believe that the Rust maintainers in the Linux project will keep on top of the C interfaces to know when there will be changes. Going back to my comment, I realize that I presented why the C developer/maintainers don't want Rust, but that is not my own stance. In my opinion, there is enough interest in the Rust for Linux project that acting as though there is only a single maintainer, and if they disappear the entire project fails and all Rust code stops compiling is unrealistic and FUD. I can see a whole host of problems being tackled, especially in driver development and safety concerns, by using Rust. I feel the C maintainers are acting as if the entire kernel is going to be rewritten in Rust in a timeframe where any of these people would still even be capable of using a keyboard or not suffering from severe dementia. My apologies to anyone that thought I was pushing for one side or the other, I was only repeating the recent "drama" that I heard was going on, and I respect both sides.