8 ms·
Rust kernel policy
- Deeg9rie9usi 2y agoThe CC list is interesting: https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ78jDHdy=9-fvZbAT8j91Je2Bxy0sFg@mail.gmail.com/ https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ...
- sylware 2y agoPlease fix rust to make its toolchains statically link libgcc. Bug since 2015...
- ChocolateGod 2y ago[flagged]
- geodel 2y agoI think it was Kurt Vonnegut who said If Rust for Linux died horribly due to a maintainer meltdown, it will not have died in vain. It will have entertained us.
- TheCleric 2y agoIt’s all open source and therefore mostly unpaid volunteer driven, but it doesn’t really feel like there is truly a policy. Every week we see a story here about a kernel maintainer complaining about Rust and Linus refusing to actually apply any sort of rules to the maintainers. It just seems very aimless and unfocused.
- giancarlostoro 2y agoMy guess is someone needs to step up and be the Linus of Rust code for Linux. It's the kind of thankless task that is invaluable, whoever can muster the courage to do it will be vital to Linux/Rust.
- baq 2y agoUnfortunately it won’t matter if the C and only C developers block generic language interoperability interfaces…
- geodel 2y ago> someone needs to step up and be the Linus of Rust code for Linux No. Better to have just Linus for Rust. Write a new OS in Rust unencumbered by C curmudgeons. As a bonus it won't be thankless but pretty exciting project on work on.
- mappu 2y agoSuch new OS exists already (Redox). It's actually really good and can run modern DEs (Cosmic) and some recent commercial games (Balatro). The problem with this direction is it dooms Linux to obsolescence. Thanks to Rust's memory safety, Redox has achieved a level of security and crash-resistance that Linux cannot hope to achieve with C. With everyone (including the US Govt) pushing for memory safe code, this has a negative impact on the whole world's major investments into Linux. To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option.
- ChocolateGod 2y ago> To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option. Isn't Zig designed as a viable solution? IIRC being easily compatible with C is one of its features.
- aw1621107 2y agoProbably depends on what exactly you're looking for in a viable solution. Zig does not provide the same level of memory safety as Rust does (IIRC it doesn't protect against data races and doesn't offer (complete?) temporal memory safety), so if what Rust provides is the bare minimum you want Zig won't cut it.
- 2y ago
- fweimer 2y agoMost development in this space (toolchain and kernel) is funded in some way. I don't know if this particular project is at some strange intersection where this isn't the case, but I would be surprised. Writing policies hard, and the environment here is somewhat challenging.
- TheCleric 2y agoI agree it’s no easy task. It seems to me though, as an outside observer, that writing virtually no enforced policy is the lazy way to go about it. Write a policy, stick to your guns, have a procedure for changing it if you get it wrong.
- dyingkneepad 2y ago> It’s all open source and therefore mostly unpaid volunteer driven The vast vast vast majority of Kernel development (and, I would guess, low-level open source software development) is paid for by companies. Here's an example. Scroll down to "Most active 6.13 employers". Unknown+None is not even 15%: https://lwn.net/Articles/1004998/ https://lwn.net/Articles/1004998/
- sunshowers 2y agoIt's not that it's volunteer driven (which it is not, as the siblings have pointed out), it's that it's distributed governance without the central authority enforcing a vision.
- progmetaldev 2y agoI 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?
- bitwize 2y agoDespite starting off "not big and professional like gnu" Linux now has trillions of dollars' worth of business going over IT infrastructure based on it. You bet your ass it's a corporate funded behemoth now, not unpaid volunteer driven. And with corporate money comes corporate governance. Ouster of Linus as the chief maintainer is definitely on the table (though not likely to ve exercised here and now). I think Linus is being wishy-washy so as not to anger either the traditional "C-niles" currently holding the kernel together or the Rust group, who are likely a more prolific source of new development. The right call here is to tell Ted Ts'o and the other old guard that they need to adjust to the new Rust reality, because things like being explicit about object lifetimes will make the C code better as well as more compatible with what the Rust side wants to do. But he either doesn't want to do that or is looking for a diplomatic way to go about it.
- okanat 2y agoThe people who contribute to kernel and especially maintain the subsystems are some of the most well-paid developers out there. If they are not a principal engineer somewhere, they have their own lucrative consultancy business.
- fweimer 2y agoProbably more relevant are the Rust version policies: https://rust-for-linux.com/rust-version-policy https://rust-for-linux.com/rust-version-policy And the policies around unstable Rust features (at least they are acknowledged as a problem): https://rust-for-linux.com/unstable-features https://rust-for-linux.com/unstable-features They don't say what their policy is regarding building the C parts with GCC and the Rust parts with the LLVM toolchain (including the Clang parts that bindgen uses). Some kernel developers are very much opposed to mixing GCC and Clang in a kernel build (to put it mildly), and some version combinations are known not to work. On the other hand, it seems somewhat unlikely that distributions would abandon building the kernel with GCC just to be able to use drivers written in Rust.
- mustache_kimono 2y ago> They don't say what their policy is regarding building the C parts with GCC and the Rust parts with the LLVM toolchain (including the Clang parts that bindgen uses). My understanding is this concern was broached very early in the Rust for Linux project and Greg Kroah Hartman explicitly signed off on "building the C parts with GCC and the Rust parts with the LLVM toolchain". See: https://news.ycombinator.com/item?id=24335831 https://news.ycombinator.com/item?id=24335831 and https://lwn.net/Articles/829858/ https://lwn.net/Articles/829858/ > And the policies around unstable Rust features (at least they are acknowledged as a problem): I am amazed at what short memories many have. I remember when clang couldn't build the kernel. I remember when GCC required many special extensions to the C language to even compile the kernel. I think GCC may still require some of these and clang/LLVM may require emulation of the same. Now, Rust gets the surprise news they may be included in the kernel and they have worked diligently to stabilize certain unstable features. Can you imagine what kind of rudder movement something similar would take to turn the C/C++ committees/tankers? Obviously, language "stability" isn't the issue you make it out to be, because, for decades, the Linux kernel required GCC extensions.
- rcxdude 2y agoIt still does, no? Linux isn't written in standard C, it's just that clang caught up with gcc in extensions.
- withinrafael 2y agoSeems like a good tool for ensuring everyone is aligned. Nit: The policy document seems inconsistent in its authoritative tone. In some sections, it hand-waves and punts to an external resource. For example: "Yes, there are key kernel maintainers who support Rust in the kernel. [Check out this PDF of keynote slides and figure it out yourself]."
- okanat 2y agoYeah. This answer is weak. If they are really supportive, they need to put down their names.
- mecsred 2y agoI think the way it was handled is pretty reasonable considering it's a public facing statement. Putting your name down on an authoritative statement is an important commitment internally, but a name put down for any reason on a public statement is a magnet for a firehose of questions, controversy, and potentially harrassment.
- bityard 2y agoWould YOU want to be named (without permission) in a document like this as being responsible for something in a high-visibility project like the kernel just because you contributed some code, or gave a talk at a conference? Anyway, some slides at a conference are not the authoritative source for who works on Rust in the Linux kernel, something this is: grep -i rust MAINTAINERS
- layer8 2y agoThe question of who has the authority over the policies regarding the integration of Rust code into the kernel seems like a different question than who is maintaining Rust code.
- hitekker 2y agoYou’ve misunderstood the GP. He liked the post and offered one suggestion; your anger is misdirected.
- HL33tibCe7 2y agoI feel like Rust just isn’t stable or mature enough as a language for moving Linux towards it to make sense. Currently feels like you need a PhD in programming languages to use it effectively. Feels like Haskell in many ways.
- nightski 2y agoKernel programming is probably one area you don’t need to optimize for newbie programmers to jump in like the web
- itishappy 2y agoI'm not sure lowering the barrier to contribute Linux kernel code is a great argument for C. It sounds like contributing code that doesn't segfault often still requires a PhD.
- escobar_west 2y agoRust and Haskell are completely different languages so I don't really agree here. Haskell doesn't have the features (lifetimes, ownership) that make Rust "hard" and Rust lets you have mutable states and procedural code. Rust is also quite stable and mature by now, I'm not sure what example or reason you're using to say otherwise.
- School-Cotton 2y agoRust and Haskell are difficult for completely different reasons. Rust is difficult for roughly the same reasons C++ is difficult.
- baq 2y agoI must protest - putting any language on par with C++ level of difficulty is unfair to C++. (Let's exclude malbolge and its relatives for a second)
- School-Cotton 2y agoI agree that rust is much less difficult than C++. But the things that are difficult about Rust are also difficult about C++… just less difficult, because the compiler helps you with them.
- lukaslalinsky 2y agoI'm an outsider, only submitted one tiny patch years ago, but it seems like this Rust for Linux initiative will end badly if it's not stopped. You have so many people involved in work on this open source OS written in C and they will be pushed to accepting foreign code. Rust, as a very complex and opinionated language, is not an easy choice to accept for C developers. If the push continues, maybe we will see the existing maintainers leaving?
- zozbot234 2y agoWe now have https://github.com/FractalFir/rustc_codegen_clr#c-support https://github.com/FractalFir/rustc_codegen_clr#c-support . So we can keep all our Rust files out-of-tree and just submit C code like everyone else.
- michaelanckaert 2y agoI can't image what reviewing C code like that would look like? Rust is a complex piece of technology, is the transpiled C code 'clean' enough to be able to review it?
- varjag 2y agoIt certainly isn't. Getting even C code written by human with best effort for addressing standards and conventions accepted is challenging enough.
- kmeisthax 2y agoThis violates the GPL.
- zozbot234 2y agoIt doesn't, because C code is clearly "the preferred form for modification" by C kernel devs that, by their own admission, are quite unwilling to deal with the perceived complexity of a multi-language code base. (Or even to learn any other programming language, for that matter.)
- sundarurfriend 2y agoThe page uses "our" and "we" a bunch of times, but doesn't say who this "we" is. The implication from the "Contact" page seems to be that this is some "Rust for Linux" group that may or may not be well defined. Which is fine, but then the document also doesn't cite most of the things it states, and isn't always clear on what's established fact/standard and what's this group's opinion. For eg. > Should maintainers treat Rust code up to the same standards? > Ideally, and eventually, yes. However, when they are starting out, not necessarily. Sections like this have no indicator for whether this is opinion they are stating, an argument they're presenting, or an already-decided kernel policy that they're citing. --- > On the costs side, [...] most Rust language features we used were stabilized The fact that this has to be specified - and still qualified with "most" - is a big part of the problem with this.
- steveklabnik 2y ago> The implication from the "Contact" page seems to be that this is some "Rust for Linux" group that may or may not be well defined. It says: > For other matters, please feel free to contact the maintainers via email. Which links to https://docs.kernel.org/process/maintainers.html#rust https://docs.kernel.org/process/maintainers.html#rust which has a list of people. There is also https://github.com/Rust-for-Linux/linux/blob/rust-next/MAINTAINERS#L20646-L20671 https://github.com/Rust-for-Linux/linux/blob/rust-next/MAINT... which is the in-tree documentation of who maintainers are. > The fact that this has to be specified - and still qualified with "most" - is a big part of the problem with this. For a very long time, linux wouldn't even compile with clang, becuase they use gcc extensions. These are effectively the same idea as nightly features. The kernel has never used standard C. Nowadays clang has enough support and keeps it going. I agree with you that I personally would much prefer that they were on 100% stable Rust, but the Linux folks in general are way more fine with depending on specific versions for the build.
- curtis3389 2y agoThe Rust for Linux politics mess should be laid squarely at Linus' feet. He's the BDFL. He approved adding Rust to Linux, and he massively failed at communicating what that even meant. If he wants Rust in the kernel, he needs to kick some maintainers in the ass and get everyone aligned.
- timewizard 2y agoAnd if he doesn't want it in the kernel?
- rcxdude 2y agoHe needs to say so before wasting everyone's time
- GuB-42 2y agoI remember seeing an interview where Linus said that at one time, he rejected a contribution and felt bad because he wasn't clear enough in that he didn't wanted that. He said he now tries to be very clear about what he doesn't want. So I guess he is ok with how things are going, otherwise, we would be likely to see another of his famous rants.
- jcarrano 2y agoExactly. The recent DRM issue was about who's time would be wasted. Rust is either happening, and they are wasting time by not having proper bindings, or it is not, and all the drivers written were a waste of time. In either case, the discussions around it are already a waste of time.
- arlort 2y agoI don't know enough to agree or disagree with the person you're replying to. But I assume the logic would be that if Linus doesn't approve then he should have shut the discussion down long ago or at least do it now without half measures
- 2y ago
- owl_vision 2y agoAny doctrine similar somehow never made it, unless the prog lang is scheme or guile or racket but i consider Tcl a lisp in disguise.
- andrewstuart 2y ago[flagged]
- saagarjha 2y agoYou’re talking about x86 assembly, right?
- andrewstuart 2y agoFalse equivalence. Assembly is unavoidable in the kernel and the the lowest level machine language and it closely related to C and is something that many C developers of kernel level capability are going to have some familiarity with. Rust is none of those things. It is not required. It is a completely different language.
- saagarjha 2y agoI’m sorry, I don’t know what “false” is. Are you perhaps talking about the macro FALSE defined as (0)?
- andrewstuart 2y agoI don't know what direction you've headed here are you trying to say Rust is good in the kernel because of the flaws/challenges in assembly? Are we into word games to confuse and distract so you can slip Rust by?
- saagarjha 2y agoI’m just poking fun at the inconsistency in your argument. Rust is a lot closer to C than assembly is. Arguments that boil down to “I can’t figure out how to read this language” are stupid because we expect kernel developers to understand a far weirder language in their day-to-day work, one with significantly less high-quality material available to get up to speed on it, and often with semantics that are not even written down anywhere. I write more assembly than Rust these days and I’d choose the latter in a heartbeat if I had to review someone else’s changes.
- andrewstuart 2y agoMy prediction: Linus will retire and leave the Rust mess for other to live with.
- dralley 2y agoThe most likely replacement for Linus as BDFL is Greg KH, who is also friendly (if anything, friendlier) towards R4L.
- hitekker 2y agoThis answer seems like a big spin: > Is Rust for Linux driven by the "Rust community"? > No, the people involved around Rust for Linux come from different backgrounds and organizations. Some are kernel maintainers, some are Rust experts. Some are hobbyists, some are employees at large corporations > Particularly, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby The Rust Project says R4L is a “flagship” goal: https://rust-lang.github.io/rust-project-goals/2024h2/goals.html https://rust-lang.github.io/rust-project-goals/2024h2/goals.... I recall Josh Triplett saying R4L was a big priority for Rust this year; he pledged his support. Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here. Edit: [1] see https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ78jDHdy=9-fvZbAT8j91Je2Bxy0sFg@mail.gmail.com/?ref=news.itsfoss.com https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ...
- sundarurfriend 2y ago> Wait a second, that’s not what this page says: https://rust-lang.github.io/rust-project-goals/2024h2/goals https://rust-lang.github.io/rust-project-goals/2024h2/goals.... I don't understand what you're saying - is your point that having Goals means that this can no longer be considered a hobby? Lots of people have hobbies where they have goals for a sense of direction and satisfaction. (Not to mention that the page doesn't say it is a hobby, just that it was started as one.) > Also, didn’t the author resign from this effort before? Or was that departure not as dramatic as I recall. Who do you mean by "the author" here? This seems to be a group effort by a "Rust for Linux" group, not a single individual.
- deleted 2y ago[deleted]
- hitekker 2y agoHey, good catch. I edited my comment to be clearer.
- HarriL 2y agoSummary: Why Rust Cannot Be Fully Integrated into the Linux Kernel Rust-for-Linux (R4L) is an experiment, but it faces fundamental obstacles due to the Linux kernel’s monolithic structure, constantly changing APIs, reliance on GCC, and existing development model. Key Challenges: 1. Unstable Kernel APIs – Linux kernel APIs frequently change, making Rust integration difficult without a stable ABI, which contradicts Linux’s development model. 2. GCC vs. LLVM Conflict – The Linux kernel primarily relies on GCC, while Rust requires LLVM. This creates fragmentation in the toolchain. 3. Dual-Language Complexity – Developers must master both C and Rust, leading to recruitment and maintenance challenges. 4. Memory Model Incompatibility – Rust’s ownership model does not align well with many kernel subsystems, requiring workarounds that reduce its safety benefits. 5. Monolithic Kernel Issues – Linux is designed as a monolith, where all components deeply interact. Introducing Rust without a complete rewrite results in complex dependencies and maintenance overhead. Only Viable Solution: A Full Fork A Rust-based kernel requires a complete fork from Linux, rewriting everything in Rust. However, such a project would no longer be Linux but an entirely new OS. Thus, Rust cannot become a true part of the Linux kernel without fundamentally breaking its principles. The real question is: Should a new Rust-based OS replace Linux, or should Rust-for-Linux be abandoned?