24 ms·

Greg K-H: "Writing new code in Rust is a win for all of us"

• stackedinserter 2y ago
  What's in Rust that creates drama in every project where it's used?
  • bmicraft 2y ago
    The part of the old guard that's hellbent on never learning anything new again, ever.
    • stackedinserter 2y ago
      Do you think that they don't want rust code in LK just because they don't want to learn "anything new again ever"?
      • bmicraft 2y ago
        Parent wasn't specifically talking about the kernel, but yes. The ones complaining in this case explicitly argued against it because they don't know it and don't want to learn it.
        • stackedinserter 2y ago
          Who said that? You?
          • iknowstuff 2y ago
            Ted tso
            • stackedinserter 2y ago
              Where did he say that the main reason rust should gtfo is that he personally doesn't want to "learn anything new, ever"?
              • iknowstuff 2y ago
                During the RfL keynote
• _zagj 2y ago
  > > > > > David Howells did a patch set in 2018 (I believe) to clean up the C code in the kernel so it could be compiled with either C or C++; the patchset wasn't particularly big and mostly mechanical in nature, something that would be impossible with Rust. Even without moving away from the common subset of C and C++ we would immediately gain things like type safe linkage. > > > > > > That is great, but that does not give you memory safety and everyone > > > would still need to learn C++. > > > > The point is that C++ is a superset of C, and we would use a subset of C++ > > that is more "C+"-style. That is, most changes would occur in header files, > > especially early on. Since the kernel uses a lot of inlines and macros, > > the improvements would still affect most of the existing kernel code, > > something you simply can't do with Rust. I have yet to see a compelling argument for allowing a completely new language with a completely different compiler and toolchain into the kernel while continuing to bar C++ entirely, when even just a restricted subset could bring safety- and maintainability-enhancing features today, such as RAII, smart pointers, overloadable functions, namespaces, and templates, and do so using the existing GCC toolchain, which supports even recent vintages of C++ (e.g., C++20) on Linux's targeted platforms. Greg's response: > But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time. side-steps this. Even if Rust is "better," it's much easier to address at least some of C's shortcomings with C++, and it can be done without significantly rewriting existing code, sacrificing platform support, or the incorporation of a new toolchain. For example, as pointed out (and as Greg ignored), the kernel is replete with macros--a poor substitute for genuine generic programming that offers no type safety and the ever-present possibility for unintended side effects due to repeated evaluation of the arguments, e.g.: #define MAX(x, y) (((x) > (y)) ? (x) : (y)) One need only be bitten by this kind of bug once to have it color your perception of C, permanently.
  • iknowstuff 2y ago
    There are clear case studies like the ones by Google (on Android) and Microsoft where introducing rust reduced vulnerabilities by 70%. In the case of android there were zero vulnerabilities discovered in new rust code. Are there similar case studies showing such clear success from adopting C++ over C? The answer appears to be no https://grok.com/share/bGVnYWN5_29baa93d-e774-45ec-898b-19bba077f511 https://grok.com/share/bGVnYWN5_29baa93d-e774-45ec-898b-19bb...
• mustache_kimono 2y ago
  But for new code / drivers, writing them in Rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? -- greg k-h
  • uecker 2y ago
    The question is to what extend this is true - given that Rust programmers also make stupid mistakes (e.g. https://rustsec.org/advisories/RUSTSEC-2023-0080.html https://rustsec.org/advisories/RUSTSEC-2023-0080.html) that look exactly like C bugs. Not that I think Rust does not have advantages in terms of safety, but probably not as much as some people seem to believe when making such arguments. The other question is at what cost it comes.
    • pajko 2y ago
      https://www.cve.org/CVERecord/SearchResults?query=rust https://www.cve.org/CVERecord/SearchResults?query=rust
      • steveklabnik 2y ago
        Some of these CVEs only exist because Rust takes security seriously. There was a filesystem bug: https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html This impacted C++'s standard library as well, but since the standard says it's undefined behavior, they said "not a bug" and didn't file CVEs. Nobody believes that Rust programs will have zero bugs or zero security vulnerabilities. It's that it can significantly reduce them.
        • BlackFly 2y ago
          To me, this attitude of the rust community is another benefit of rust: there is a general commitment that idiomatic rust code handles and exposes when things can go wrong.
      • merb 2y ago
• orf 2y ago
  Christoph Hellwig seems fun to interact with. He drive-by posts the same, repeated points and seemingly refuses to engage with any replies.
  • rendaw 2y ago
    AFAICT his only response in that thread: > Right now the rules is Linus can force you whatever he wants (it's his project obviously) and I think he needs to spell that out including the expectations for contributors very clearly. > > For myself I can and do deal with Rust itself fine, I'd love bringing the kernel into a more memory safe world, but dealing with an uncontrolled multi-language codebase is a pretty sure way to get me to spend my spare time on something else. I've heard a few other folks mumble something similar, but not everyone is quite as outspoken. He gets villianized and I don't think all his interactions were great, but this seems pretty reasonable and more or less in line with what other people were asking for (clearer direction from Linus). That said, I don't know, maybe Linus's position was already clear...
    • buttercraft 2y ago
      Maybe, but "spreads like cancer" is not part of a well-reasoned technical discussion, but of an emotional one.
      • sph 2y ago
        In many languages, like Italian which I am a native speaker of, to "spread like a cancer" doesn't have the negative subtext of the English idiom. It just means it spreads, wildly, uncontrollable. In English it gets muddled with the very negative idiom of "being a cancer", i.e. being very bad if not fatal.
        • indrora 2y ago
          I think it's because in English-speaking places (I'll say "The US and some rounding errors" to be explicit) the fact is that for a long time, cancer was a death sentence. This led to anything that is hard to kill as being called cancerous and the avoidance of such things is important (yes, this is where you chuckle and mime smoking a cigarette. There's still a population of the US that believes "smoking causes cancer" is a conspiracy by Big Pharma to push more cancer treatments or some bullshit like that.) Calling something "cancerous" is to say it was an incurable disease that unless stamped out with some amount of precision will continue to cause rot and decay. Be it correct or not, saying "The cancer that is killing HN" is pointing a finger at a problem and scapegoating all the other problems onto it.
• MalseMattie 2y ago
  This statement was sorely needed for this discussion to move forward. Hopefully the last section fills the needed parties with resolve
• dfawcus 2y ago
  The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. Possibly also that a significant portion of the suggested gain may be achievable via other means. i.e. bounds checking and some simple (RAII-like) allocation/freeing simplifications may be possible without rust, and that those are (from the various papers arguing for Rust / memory safety elsewhere) the larger proportion of the safety bugs which Rust catches. Possibly just making clang the required compiler, and adopting these extension may give an easier bang-for-buck: https://clang.llvm.org/docs/BoundsSafety.html https://clang.llvm.org/docs/BoundsSafety.html Over and above that, there seem to be various complaints about the readability and aesthetics of Rust code, and a desire not to be subjected to such.
  • mustache_kimono 2y ago
    > The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. Read the above email. Greg KH is pretty certain it is worth the gain. > Possibly also that a significant portion of the suggested gain may be achievable via other means. I think this is a valid POV, if someone shows up and does the work. And I don't mean 3 years ago. I mean -- now is as good a time as any to fix C code, right? If you have some big fixes, it's not like the market won't reward you for them. It's very, very tempting to think there is some other putatively simpler solution on the horizon, but we haven't seen one. > Over and above that, there seem to be various complaints about the readability and aesthetics of Rust code, and a desire not to be subjected to such. No accounting for taste, but I don't think C is beautiful! Rust feels very understandable and explicit to my eye, whereas C feels very implicit and sometimes inscrutable.
    • whstl 2y ago
      > Read the above email. Greg KH is pretty certain it is worth the gain. I don't think GP or anyone is under the impression that Greg KH thinks otherwise. He's not the "some folks" referred here.
      • 2y ago
• stpedgwdgfhgdd 2y ago
  No pain, no gain
• deleted 2y ago
  [deleted]
• mimd 2y ago
  Isn't this a bait and switch, that all the c kernel devs were complaining about? That it wouldn't be just drivers but also all new kernel code? The lack of candor over the goal of R4L and downplaying of other potential solutions should give any maintainer (including potential rust ones) pause. Anyway, why just stop at rust? If we really care about safety, lets drop the act and go make everyone do formal methods. Frama-C is at least C, has a richer contract language, has heavy static analysis tools before having to go to proofs, is much more proven, and the list goes on. Or, why not add Spark to the codebase if we are okay with mixing langs in the codebase? Its very safe.
  • AlotOfReading 2y ago
    Frama-C doesn't actually prove memory safety and has a huge proof hole due to the nature of UB. It gives weaker guarantees than Rust in many cases. It's also far more of a pain to write. The Frama-C folks have been using the kernel as a testbed for years and contributing small patches back. The analysis just doesn't scale well enough to involve other people. Spark doesn't have an active community willing to support its integration into the kernel and has actually been taking inspiration from Rust for access types. If you want to rustle up a community, go ahead I guess?
    • mimd 2y ago
      No, it can track pointer bounds and validity across functions. It also targets identifying cases of UB via eva. Both rust and frama-C rely on assertions to low level memory functions. Rust has the same gaping UB hole in unsafe that can cross into safe. If we are talking about more than memory, such as what greg is talking about in encoding operational properties then no, rust is far behind both frama-C, Spark, and tons of others. They can prove functional correctness. Or do you think miri, kani, cruesot, and the rest of the FM tools for Rust are superfluous? My mocking was that that the kernel devs have had options for years and have ignored them out of dislike (ada and spark) or lack of effort (frama-C). That other options provide better solutions to some of their intrests. And that this is more a project exercise in getting new kernel blood than technical merits.
  • gizmondo 2y ago
• p_ing 2y ago
  > the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible What is he referring to?
  • jcranmer 2y ago
    I can think of several issues with the C++ committee that people can reasonably point to (some of them mutually contradictory even!), but I have no idea which of them is being referred to. It's possible he's referring to profiles, which is one of those cases where there's mutually contradictory criticisms that can be leveled against it so I have no idea in that case if he thinks they're a good or a bad thing. Personally, the biggest issue that gives me fear for C++'s future is that the committee seems to have more or less stopped listening to implementer feedback and concerns.
  • zamalek 2y ago
    You could probably look up the reasons for Carbon's existence as an answer. Actually, I did the legwork for you[1]. [1]: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md https://github.com/carbon-language/carbon-lang/blob/trunk/do...
  • saagarjha 2y ago
    Presumably the endless documents they keep coming out with explaining how profiles will solve memory safety Or whatever
  • mikeyouse 2y ago
    I think the latest drama where they won’t commit to taking memory safety seriously; https://thenewstack.io/c-committee-divided-on-memory-safety-plans/ https://thenewstack.io/c-committee-divided-on-memory-safety-...
  • jodrellblank 2y ago
    https://izzys.casa/2024/11/on-safe-cxx/ https://izzys.casa/2024/11/on-safe-cxx/ is a long and opinionated drama and swear-filled read on the topic. snips from it: > "many people reading this might be familiar with the addition of the very powerful #embed preprocessor directive that was added to C. This is literally years of work brought about by one person, and that is JeanHeyd Meneide. JeanHeyd is a good friend and also the current editor of the C standard. And #embed started off as the std::embed proposal. Man, if only everyone in the world knew what the C++ committee did to fucking shut that shit down..." > ... "Herb [Sutter] ... spun up a Study Group, SG15, at the recommendation of GDR to handling “tooling” in the C++ ecosystem. This of course, paved the way for modules to get absolutely fucking steamrolled into the standard while allowing SG15 to act as a buffer preventing any change to modules lest they be devoid of Bjarne [Stroustrup] and Gaby [Gabriel Dos Reis]’s vision. Every single paper that came out of SG15 during this time was completely ignored." > "Gaby [Gabriel Dos Reis] is effectively Bjarne’s protégé. ... when it came to modules Gaby had to “prove himself” by getting modules into the language. Usually, the standard requires some kind of proof of implementation. This is because of the absolute disaster that was export template, a feature that no compiler that could generate code ever implemented. Thus, proof of modules workability needed to be given. Here’s where I bring in my personal conspiracy theory. The only instance of modules being used prior to their inclusion in the standard was a single email to the C++ mailing lists (please recall the amount of work the committee demanded from JeanHeyd for std::embed) where Gaby claimed that the Microsoft Edge team was using the C++ Modules TS via a small script that ran NMake and was “solving their problem perfectly”." ... the face she made when I asked [a Microsoft Employee] about Gaby’s statement signaled to me that the team was not happy. Shortly after modules were confirmed for C++20, the Microsoft Edge team announced they were throwing their entire codebase into the goddamn garbage and just forking Chromium... Gaby Dos Reis fucking lied, but at least Bjarne got what he wanted. ... This isn’t the first time Gaby has lied regarding modules, obviously...." > ... "This [different] paper is just frankly insulting to anyone who has done the work to make safer C++ syntax, going on to call (or at least allude to) Sean Baxter’s proposal an “ad hoc collection of features”. Yet another case of Gaby’s vagueries where he can feign ignorance. As if profiles themselves are not ad hoc attributes, that have the exact same problem that Bjarne and others argue against, specifically that of the virality of features. The C++ committee has had 8 years (8 long fucking years) to worry about memory safety in C++, and they’ve ignored it. Sean Baxter’s implementation for both lifetime and concurrency safety tracking has been done entirely in his Circle compiler [which] is a clean room, from the ground up, implementation of a C++ compiler. If you can name anyone who has written a standards conforming C++ compiler frontend and parser and then added metaprogramming and Rust’s lifetime annotation features to it, I will not believe you until you show them to me. Baxter’s proposal, P3390 for Safe C++ has a very large run down on the various features available to us..." > "Bjarne has been going off the wall for a while now regarding memory safety. Personally I think NASA moving to Rust hurt him the most. He loves to show that image of the Mars rover in his talks. One of the earliest outbursts he’s had regarding memory safety is a very common thing I’ve seen which is getting very mad that the definition a group is using is not the definition he would use and therefore the whole thing is a goddamn waste of time." > "You can also look at how Bjarne and others talk about Rust despite clearly having never used it. And in specifically in Bjarne’s case he hasn’t even used anything outside of Visual Studio! It’s all he uses. He doesn’t even know what a good package manager would look like, because he doesn’t fucking care. He doesn’t care about how asinine of an experience that wrangling dependencies feels like, because he doesn’t have to. He has never written any actual production code. It is all research code at best, it is all C++, he does not know any other language." > "Orson Scott Card didn't write Ender's Game [link] -> Ender's Game is an apologia for Hitler" > "this isn’t a one off situation. It isn’t simply just Bjarne who does this. John Lakos of Bloomberg has also done this historically, getting caught recording conversations during the closing plenary meeting for the Kona 2019 meeting because he didn’t get his way with contracts. Ville is another, historically insulting members and contributors alike (at one point suggesting that the response to a rejected paper should be “fuck you, and your proposal”), and I’m sure there are others, but I’m not about to run down a list of names and start diagnosing people like I’m a prominent tumblr or deviantart user in 2017." > "the new proposed (but not yet approved) Boost website. This is located at boost.io and I’m not going to turn that into a clickable link, and that’s because this proposed website brings with it a new logo. This logo features a Nazi dog whistle. The Nazi SS lightning bolts. Here’s a side by side of the image with and without the bolts being drawn over (Please recall that Jon Kalb, who went out of his way to initially defend Arthur O’Dwyer, serves on the C++ Alliance Board)." > "Arthur O’Dwyer has learnt to keeps his hands to himself, he does not pay attention to or notice boundaries and really only focuses on his personal agenda. To quote a DM sent to me by a C++ community member about Arthur’s behavior “We are all NPCs to him”. He certainly doesn’t give a shit. He’s been creating sockpuppets, and using proxies to get his changes into the LLVM and Clang project. Very normal behavior by the way." > "This is the state C++ is in, though as I’ve said plenty of times in this post, don’t get it twisted. Bjarne ain’t no Lord of Cinder. We’re stuck in a cycle of people joining the committee to try to improve the language, burning out and leaving, or staying and becoming part of the cycle of people who burn out the ones who leave."
• throwaway984393 2y ago
  [dead]
• chris_wot 2y ago
  "he C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time." I'd love to know where he got this impression. The new C++ features go a long way to helping make the language easier, and safer, to use.
  • ultimaweapon 2y ago
    Of course the modern C++ are safer but you can still shoot yourself in the foot. Compared to Rust you still need to think about the memory safety when writing C++ while Rust you don't need to think about it at all. The only time you need to think about the memory safety in Rust is when using unsafe keyword, which can be isolated into a dedicated function. Most C++ developers may don't understand what I mean. You need to proficient in Rust in order to understand it. When I was still using C++ as my primary language I have the same feeling as the other C++ developers about Rust. Once you start to comfortable with Rust you will see it is superior than C++ and you don't want to use C++ anymore.
  • chippiewill 2y ago
    C++ _has_ been getting safer and safer to write. However: 1. The dangerous footguns haven't gone away 2. There are certain safety problems that simply can't be solved in C++ unless you accept that ABI will be broken and the language won't be backwards compatible. Circle (https://www.circle-lang.org/site/index.html https://www.circle-lang.org/site/index.html) and Carbon (https://docs.carbon-lang.dev/ https://docs.carbon-lang.dev/) were both started to address this fundamental issue that C++ can't be fully fixed and made safe like Rust without at least some breaking changes. This article goes into more depth: https://herecomesthemoon.net/2024/11/two-factions-of-cpp/ https://herecomesthemoon.net/2024/11/two-factions-of-cpp/ In the case of the Linux kernel, a lot of the newer features that C++ has delivered aren't _that_ useful for improving safety because kernel space has special requirements which means a lot of them can't be used. I think Greg is specifically alluding to the "Safety Profiles" feature that the C++ committee looks like it will be going with to address the big safety issues that C++ hasn't yet addressed - that's not going to land any time soon and still won't be as comprehensive as Rust.
• chris_wot 2y ago
  "Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to "ensure that you got this right" that is a combination of both how our apis have evolved over the years" Funny, that's not Theodore T'so's position. The Rust guys tried to ask about interface semantics and he yelled at them: https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s https://www.youtube.com/watch?v=WiPp9YEBV0Q&t=1529s
  • tptacek 2y ago
    I watched like 2 minutes of this and I don't understand what this is supposed to be saying about the current debate. There's a guy lecturing the audience about how there are 30 filesystems in the kernel and not all of them are going to be instantaneously converted to Rust. But gregkh and kees aren't suggesting that any of them be converted to Rust!
    • dralley 2y ago
      It's only relevant to the current debate in the sense that that event was the trigger for Wedson (the first and OG R4L project contributor) to quit, which was only a few months ago, so it's a fresh wound marinating in the background while essentially the same drama unfolds all over again.
  • vixu 2y ago
    There's an email from Ted in this thread. It's really cool to see how his perspective changed since the video blew up. https://lore.kernel.org/rust-for-linux/20250219170623.GB1789203@mit.edu/ https://lore.kernel.org/rust-for-linux/20250219170623.GB1789...
• darksaints 2y ago
  I've been using Linux since 2005, and I've loved it in almost every circumstance. But the drama over the last couple of years surrounding Rust in the kernel has really soured me on it, and I'm now very pessimistic about its future. But I think beyond the emotional outbursts of various personalities, I don't think that the problem is which side is "right". Both sides have extremely valid points. I don't think the problem is actually solvable, because managing a 40M+ SLoC codebase is barely tenable in general, and super duper untenable for something that we rely on for security while running in ring 0. My best hope is for replacement. I think we've finally hit the ceiling of where monolithic kernels can take us. The Linux kernel will continue to make extremely slow progress while it deals with internal politics fighting against an architecture that can only get bigger and less secure over time. But what could be the replacement? There's a handful of fairly mature microkernels out there, each with extremely immature userspaces. There doesn't seem to be any concerted efforts behind any of them. I have a lot of hope for SeL4, but progress there seems to be slow mostly because the security model has poor ergonomics. I'd love to see some sort of breakout here.
  • bigfatkitten 2y ago
    > I have a lot of hope for SeL4, but progress there seems to be slow mostly because the security model has poor ergonomics. seL4 has its place, but that place is not as a Linux replacement. Modern general purpose computers (both their hardware, and their userspace ecosystems) have too much unverifiable complexity for a formally verified microkernel to be really worthwhile.
    • darksaints 2y ago
      I agree that SeL4 won't replace Linux anytime soon, but I beg to differ on the benefits of a microkernel, formally verified or not. Any ordinary well-designed microkernel gives you a huge benefit: process isolation of core services and drivers. That means that even in the case of an insecure and unverified driver, you still have reasonable expectations of security. There was an analysis of Linux CVE's a while back and the vast majority of critical Linux CVEs to that date would either be eliminated or mitigated below critical level just by using a basic microkernel architecture (not even a verified microkernel). Only 4% would have remained critical. https://microkerneldude.org/2018/08/23/microkernels-really-do-improve-security/ https://microkerneldude.org/2018/08/23/microkernels-really-d... The benefit of a verified microkernel like SeL4 is merely an incremental one over a basic microkernel like L4, capable of capturing that last 4% and further mitigating others. You get more reliable guarantees regarding process isolation, but architecturally it's not much different from L4. There's a little bit of clunkiness for writing userpace drivers for SeL4 that you wouldn't have for L4. That's what the LionsOS project is aiming to fix.
• deleted 2y ago
  [deleted]
• infogulch 2y ago
  The actual project is "lets modernize the internal kernel api surface", and "how tolerable is it to write against this api in rust" is just the best metric at hand to measure the progress. This is the correct frame for RFL proponents. You're welcome.
  • dralley 2y ago
    That's hardly a novel framing. It's even brought up in the very email thread (not by Greg KH) that we're discussing.
    • infogulch 2y ago
      Oh good. I haven't had an afternoon free to read that whole thread yet, got a link?
      • int_19h 2y ago
        https://lore.kernel.org/rust-for-linux/20250219150553.GD15114@pendragon.ideasonboard.com/ https://lore.kernel.org/rust-for-linux/20250219150553.GD1511...
        • dralley 2y ago
          Also https://lore.kernel.org/rust-for-linux/1f52fa44062e9395d54ed6733780aea0830ee6a5.camel@HansenPartnership.com/T/#mfa44b50581e944d758b68b447340aa1108cb3ba2 https://lore.kernel.org/rust-for-linux/1f52fa44062e9395d54ed...
          • infogulch 2y ago
            I'm glad to see this idea bounce around, even if it's not put quite as pointedly as my description above.
• lousken 2y ago
  I wonder how Microsoft implements rust in their kernel. As for this issue, it's just a nature of any project, people will come and go regardless, so why not let those C developers leave and keep the rust folks instead? At some point you have to steer the ship and there will always be a group of people unhappy about the course
  • 000ooo000 2y ago
    MBA moment
  • bigfatkitten 2y ago
    Alternatively, there's nothing preventing the Rust folks building their own kernel from the ground up.
    • dralley 2y ago
      There are multiple kernels written in Rust already. Writing another one wouldn't be interesting. The point of R4L is that people want to write drivers for Linux in Rust. The corporate sponsors that are involved also are interested in writing drivers for Linux in Rust. Sure, Google could rebase Android on top of RedoxOS or Fuschia and Red Hat could spend a decade writing Linux Subsystem for RedoxOS, but neither want to do those things. They want to write drivers, for Linux, in Rust. Telling them to write a new kernel is a bit like telling them they should go write a new package manager. It's a completely different thing from what they actually care about.
      • patrick451 2y ago
        [flagged]
        • dralley 2y ago
          Both Linus and Greg KH were actively supportive of the project and remain so. Several of the R4L developers were long-term linux devs long before the project started (e.g. David Arlie). There are lots of current maintainers who aren't directly involved with R4L that still have a positive and optimistic outlook about it long-term. Just because there are a handful of maintainers are vocally in opposition does not mean that is the representative opinion. This is such an absurd, content-free argument, which is not surprising given how you closed it.
• stefantalpalaru 2y ago
  [dead]
• voidr 2y ago
  We should have seen this post before Hector Martin got so fed up that he decided to resign(to be fair, he probably had other issues as well that contributed). I was very confused by the lack of an actual response from Linus, he only said that social media brigading is bad, but he didn't give clarity on what would be the way forward on that DMA issue. I have worked in a similar situation and it was the worst experience of my work life. Being stonewalled is incredibly painful and having weak ambiguous leadership enhances that pain. If I were a R4L developer, I would stop contributing until Linus codifies the rules around Rust that all maintainers would have to adhere to because it's incredibly frustrating to put a lot of effort into something and to be shut down with no technical justification.
  • zamalek 2y ago
    You know, the complaint is that R4L would add undue load to existing maintainers (at least that's about the only coherent technical thing I've gathered from Christoph's emails). What also adds undue load to existing maintainers is causing their peers to quit. Hector Martin is a talented individual and the loss of him will surely be felt.
  • dralley 2y ago
    Clarity was apparently provided privately. However, I have to say that a public statement would have been better. I can only imagine how demoralizing it is for the R4L contributors to watch their work being trashed in public and the leadership is only privately willing to give reassurances. Not to mention bad for recruitment.
    • preisschild 2y ago
      > Clarity was apparently provided privately Only to Hedwig if I understood correctly
• daft_pink 2y ago
  It’s hard. Most people agree it should have memory safety, but also I’m not looking to become a full scale maintainer either.
• okl 2y ago
  Seems to me that everyone is focused on the technical merits, not weighing the effort of learning a new programming language/toolchain/ecosystem for the maintainers appropriately. Mastering a new programming language to a degree that makes one a competent maintainer is nothing to sneeze at and some maintainers might be unwilling to based on personal interests/motivation, which I'd consider legitimate position. I think its important to acknowledge that not everyone may feel comfortable talking about their lack of competence/disinterest.
  • braiamp 2y ago
    And sadly, those are going to die out eventually, so the faster we get there, the less potentials for something breaking in a way that nobody would be able to figure it out.
    • aldanor 2y ago
      Who will, technical merits, programming languages or maintainers?
  • KerrAvon 2y ago
    Acknowledged, but said maintainers need to learn to cope with the relentless advance of technology. Any software engineer with a long career needs to be able to do this. New technology comes along and you have to adapt, or you become a fossil. It's totally fine on a personal level if you don't want to adapt, but you have to accept that it's going to limit your professional options. I'm personally pretty surly about learning modern web crap like k18s, but in my areas of expertise, I have a multi-decade career because I'm flexible with languages and tools. I expect that if AI can ever do what I do, my career will be over and my options will be limited.
    • manmal 2y ago
      Totally tangential, but since I just recently found this out: character-number-character, like [k8s, a16z, a11y] means that 8/16/11 characters in the middle are replaced by their count. I was wondering why kubernetes would be such a long word, when you wrote k18s. Maybe it was just a typo on your end, and this system is totally obvious.
• AshamedCaptain 2y ago
  I do not understand how this is supposed to work in practice. If there are "Rust bindings" then the kernel cannot have a freely evolving internal ABI, and the project is doomed to effectively split into the "C" core side and the "Rust" side which is more client oriented. Maybe it will be a net win for Linux for finally stabilizing the internal APIs, and even open the door to other languages and out-of-tree modules. On the other hand, if there are no "Rust bindings" then Rust brings very little to the table.
  • saagarjha 2y ago
    You can rewrite a lot of stuff in Rust and offer C bindings to it.
    • lucasyvas 2y ago
      Rust is better used from the inside out. It’s just more controversial.
  • TransAtlToonz 2y ago
    I don't understand why rust bindings imply a freezing (or chilling) of the ABI—surely rust is bound by roughly the same constraints C is, being fully ABI-compatible in terms of consuming and being consumed. Is this commentary on how Rust is essentially, inherently more committed to backwards compatibility, or is this commentary on the fact that two languages will necessarily bring constraints that retard the ability to make breaking changes?
    • AshamedCaptain 2y ago
      Obviously the latter, which is already the point of contention that has started this entire discussion.
      • TransAtlToonz 2y ago
        Can you explain why you think this? I don't understand the reasoning and it's certainly not "obvious". There's certainly no technical reason implying this, so is this just resistance to learning rust? C'mon, kernel developers can surely learn new tricks. This just seems like a defeatist attitude. EDIT: The process overhead seems straightforwardly worth it—rust can largely preserve semantics, offers the potential to increase confidence in code, and can encourage a new generation of contribution with a faster ramp-up to writing quality code. Notably nowhere here is a guarantee of better code quality, but presumably the existing quality-guaranteeing processes can translate fine to a roughly equivalently-capable language that offers more compile-time mechanisms for quality guarantees.
• wewewedxfgdf 2y ago
  Community and people are the main issue. If the people who work on the kernel now don't like that direction then that's a big problem. The Linux leadership don't seem very focused on the people issues. Where is the evidence that there is buy in from the actual people doing kernel development now? Or is it just Linus and Greg as commanders saying "thou shalt".
  • dralley 2y ago
    Plenty of Linux maintainers are either fully or partially on board with using Rust in drivers. Don't overindex on the opinions of two or three of them that are vocally opposed / skeptical. Christian is a special case because his subsystem (DMA) is essentially required for the vast majority of useful device drivers that one might want to write. Whereas other subsystems are allowed to go at their own pace, being completely blocked on DMA access by the veto of one salty maintainer would effectively doom the whole R4L project. So whereas normally Linus would be more willing to avoid stepping on any maintainer's toes, he kind of has to here.
    • EasyMark 2y ago
      I guess I simply don't understand why he's biased against rust folks using his API as long as they aren't mucking about on his lawn. Why does he care? If the API and calling conventions are adhered to it makes absolutely no difference to him or the hardware that it's running on. I don't understand his objections. If I write a c library or network service, I don't care if the person using it is using rust, c, ada, or cobol...
      • dralley 2y ago
        Linus appears to agree https://lore.kernel.org/rust-for-linux/1f52fa44062e9395d54ed6733780aea0830ee6a5.camel@HansenPartnership.com/T/#m2cd4563694b50fee0aaadfe7efcf32c10ecb1c6c https://lore.kernel.org/rust-for-linux/1f52fa44062e9395d54ed...
      • chippiewill 2y ago
        To play devil's advocate: 1. He has a philosophical objection to a multi-lingual kernel, because it adds complexity, and it's not unreasonable to expect that to spread. 2. It's fair enough to say it doesn't impact him now. But realistically if Rust is a success and goes beyond an experiment then at some point (e.g. in a decade) it will become untenable for subsystem maintainers to break the rust bindings with changes and let someone else fix them before releases. I fully expect that there will be very important drivers written in Rust in the future and it will be too disruptive to have the Rust build break on a regular basis just because Hellwig doesn't want to deal with it every time the DMA APIs are changed. So unsurprisingly Hellwig is reacting now, at the point when he can exert the most control to avoid being forced to either accept working on doing some Rust himself or be forced to step aside and let someone else do it. However this isn't realistically good enough. Linus already called the play when he merged the initial Rust stuff, the experiment gets to go on. The time to disagree and commit was back then.
• cynicalsecurity 2y ago
  Rust changes every few months. It's simply not a mature language or people behind it have no idea what they are doing.
  • EasyMark 2y ago
    It's not the rust of 8-10 years ago, it's quite stable as a language now, and backward compatibility is stellar.
  • saagarjha 2y ago
    It turns out that there are always things to improve. You can decide to ignore those improvements for 50 years too but then people generally don’t want to use your language anymore.
    • deleted 2y ago
      [deleted]
  • oconnor663 2y ago
    If you haven't been maintaining any Rust code, you might have the impression that breaking changes are far more common than they really are. Rust has about as many breaking changes as Go, probably fewer? (Because Go lacks an edition mechanism.)
    • bmicraft 2y ago
      Which means that rust doesn't have any, does it? Since existing editions will (knock on wood) never change they should never break...
      • estebank 2y ago
        Yes, except for fixing soundness bugs (very rare in the past several years) and changes to the stdlib that might interact poorly with type inference and existing code (the time 0.3.5 issue, which is a change that breaks existing code, because the existing code technically was already "broken"/exercise a future compat footgun, but these should be about as unusual).
• nailer 2y ago
  Pasting the entire thing so people on mobile can read (at least on iPhone readability doesn’t work here: As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic. The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.) I'm all for moving our C codebase toward making these types of problems impossible to hit, the work that Kees and Gustavo and others are doing here is wonderful and totally needed, we have 30 million lines of C code that isn't going anywhere any year soon. That's a worthy effort and is not going to stop and should not stop no matter what. But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time. Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to "ensure that you got this right" that is a combination of both how our apis have evolved over the years (how many different ways can you use a 'struct cdev' in a safe way?) and how C doesn't allow us to express apis in a way that makes them easier/safer to use. Forcing us maintainers of these apis to rethink them is a GOOD thing, as it is causing us to clean them up for EVERYONE, C users included already, making Linux better overall. And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I'm willing to learn and work with the developers who have stepped up to help out here. To not want to learn and change based on new evidence (see my point about reading every kernel bug we have.) Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that? Linux is a tool that everyone else uses to solve their problems, and here we have developers that are saying "hey, our problem is that we want to write code for our hardware that just can't have all of these types of bugs automatically". Why would we ignore that? Yes, I understand our overworked maintainer problem (being one of these people myself), but here we have people actually doing the work! Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together. thanks, greg k-h
• npalli 2y ago
  Prediction 2030: Linus Retires and C++ accepted as the primary language for writing the kernel. Inadvertently, Rust makes working with C++ acceptable.
  • fooker 2y ago
    You might be onto something. Android already uses a hardware abstraction layer for Linux written in C++ to write drivers. It's a matter of politics to get something like this into the kernel.
• dboreham 2y ago
  I think it's becoming apparent that any attempt to progressively re-write a large codebase into a new language is always going to fail. Needs to done ground up new.
  • bmicraft 2y ago
    Not huge, but the incremental approach pretty much couldn't have gone better for fish: https://fishshell.com/blog/rustport/ https://fishshell.com/blog/rustport/
  • baq 2y ago
    Ummm it’s actually exactly the other way around if the code is alive: incremental is the only possible way to keep up.
  • fulafel 2y ago
    Which progressive rewrite attempts do you have in mind?
• typ 2y ago
  In my honest opinion, it's not a good idea to mix two programming languages into the same monolithic codebase side by side. It would be less problematic if used for different purposes or layers, like frontend and backend. But we know it still creates unpleasant friction when you have to work on both sides on your own. Otherwise, it creates technical AND communication friction if the C devs and Rust devs work separately. As someone who works with embedded systems at times, I can imagine the pain that you have to set up two toolchains (with vastly different build infra beasts like GNU Make and Cargo) and the prolonged build time of CI and edit-compile-run debugging cycles given the notorious slow compile time of the Rust/LLVM compiler.
  • whydid 2y ago
    I can imagine a possible future of 100% Rust takeover of the kernel.
    • preisschild 2y ago
      It doesn't even need to be 100% rust to gain most rust benefits. Just by forcing new features to be written in rust, it will decrease potential memory safety related bugs / vulnerabilities drastically https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html https://security.googleblog.com/2024/09/eliminating-memory-s...
  • eviks 2y ago
    > the prolonged build time of CI and edit-compile-run debugging cycles Does Linux kernel development have hot reload on the C side as a comparison?
    • aaronmdjones 2y ago
      It used to, until Oracle bought it out. It is not usable for changes to the ABI though; only kernel functions. The use case was hot-patching a running kernel to fix a security vulnerability in e.g. a device driver, but it could be used to modify almost any function. https://en.wikipedia.org/wiki/Ksplice https://en.wikipedia.org/wiki/Ksplice
• lazypenguin 2y ago
  Linus response here seems relevant to this context: https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mail.gmail.com/ https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...
  • yolovoe 2y ago
    Huh, thanks. Really good to know where Linus stands here. Seems to me like Linus is completely okay with introduction of Rust to the kernel and will not allow maintainers blocking its adoption. Really good sign. Makes me hopeful about the future of this increasingly large kernel
  • thesuperbigfrog 2y ago
    Linus's reply is perfect in tone and hopefully will settle this issue. He is forceful in making his points, but respectful in the way he addressed Christoph's concerns. This gives me great hope that the Linux maintainer community and contributers using Rust will be able to continue working together, find more common ground, and have more success.
    • nxobject 2y ago
      Linus is one of the few people who can forcefully argue the case for moderation, and I've recognized some of the lines I've used to shift really contentious meetings back into place. There's the "shot-and-chaser" technique (a) this is what needs to happen now for the conversation... "I respect you technically, and I like working with you[...] there needs to be people who just stand up to me and tell me I'm full of shit[...] But now I'm calling you out on YOURS." ...and (b) this is me recognizing that me taking charge of a conversation is a different thing than me taking control of your decisions: "And no, I don't actually think it needs to be all that black-and-white." (Of course Linus has changed over time for the better, he's recognized that, and I've learned a lot with him and have made amends with old colleagues.)
      • kelnos 2y ago
        I really liked this reply from Torvalds. I've seen a lot of his older rants, and while I respect his technical achievements, it really turned me off on the guy himself. I was skeptical of his come-to-jesus moment back in 2018 (or whenever it was), but these days it's great to read his measured responses when there's controversy. It's really cool to see someone temper their language and tone, but still keep their tell-it-like-it-is attitude. I probably wouldn't feel good if I were Christoph Hellwig reading that reply, but I also wouldn't feel like someone had personally attacked me and screamed at me far out of proportion to what I'd done.
• tsunego 2y ago
  [dead]
• WalterBright 2y ago
  These days, the bugs I generate in my own code are rarely programming errors. They're misunderstandings of the problem I am trying to solve, or misunderstandings of how to fit it into the rest of the (very complex) code. For example, I cannot even recall the last time I had a double-free bug, though I used to do it often enough. The emphasis for me is on a language that makes it easy to express algorithms.
  • jcranmer 2y ago
    > For example, I cannot even recall the last time I had a double-free bug Honestly, it's not the double-frees I worry about, since even in a language like C where you have no aids to avoid it, the natural structure of programs tends to give good guidance on who is supposed to free an object (and if it's unclear, risking a memory leak is the safer alternative). It's the use-after-free I worry about, because this can come about when you have a data structure that hands out a pointer to an element that becomes invalid by some concurrent but unrelated modification to that data structure. That's where having the compiler bonk me on the head for my stupidity is really useful.
  • yazaddaruvala 2y ago
    +1 I’ve really enjoyed using more declarative languages in recent years. At work I’ve been helping push “use SQL with the best practices we learned from C++ and Java development” and it’s been working well. It’s identical to your point. We no longer need to care about pointers. We need to care about defining the algorithms and parallel processing (multi-threaded and/or multi-node). Fun fact: even porting optimized C++ to SQL has resulted in performance improvements.
• mmooss 2y ago
  Regarding the Linux development process: How do Linux maintainers / contributors have time to read these long threads of long posts? Just this one discussion looks like it would take hours to read and these are busy developers. How does it work? Are there only a few threads that they read? Which ones?
  • mburns 2y ago
    This hacker news post has more comments than the mailing list thread that inspired it. A roughly comparable amount of text. It’s a lot, but certainly doable. That + having a couple decades to refine your email client setup goes a long way.
  • meibo 2y ago
    Not sure if you've made this experience yet, but the one thing I've learned about being an involved maintainer of a sizeable open source project is that it's mostly about communicating. You'll be talking to a lot of people and making sure that everyone is on the same page, and that's what's going on here, hopefully. If you just shut up and write code all day, you probably aren't gonna get there and there will be conflict, especially if other people are touching your systems and aren't expecting your changes.
    • buzzardbait 2y ago
      In the 20 years that I've been working on sizeable closed source projects, it's also mostly about communicating. Even if the team is small, it's mostly about communicating. Occasionally some developers don't want to communicate, and prefer to shut up and write code all day, like you said. That usually creates more conflict due to different expectations, regardless of how brilliant you are.
      • theshrike79 2y ago
        And if the team is remote and distributed (like the Linux kernel team has been pretty much always), communication and documentation is even more important. There is no "silent information" being distributed by random conversations around the office. If something is not explicitly written down, it did not happen and doesn't exist.
• oguz-ismail 2y ago
  Aren't these people tired of shaving that yak already? I wish they rather focused on making one (1) decent distro for desktop use.
  • bmicraft 2y ago
    Kernel developers aren't generally in the business of creating distros
• kelnos 2y ago
  It's really disappointing to me to see a lot of the negative reactions and comments here. I know it's popular and in vogue now to hate on Rust, but: Influential people who have worked on the ins and outs of the Linux kernel for years and decades believe that adopting Rust (or at least keeping the Rust experiment going) is worth the pain it will cause. That's really all that matters. I see people commenting here about how they think RAII isn't suitable for kernel code, or how keeping C and Rust interfaces in sync will slow down important refactoring and changes, or how they think it's unacceptable that some random tiny-usage architecture that Rust/LLVM doesn't support will be left behind, or... whatever. So what! I'm not a Linux kernel developer or maintainer, and I suspect most (if not all) of the people griping here aren't either. What does it matter to you if Linux adopts Rust? Your life will not be impacted in any way. All that matters is what the maintainers think. They think this is a worthwhile way to spend their time. The people putting in the work get to decide.
• marhee 2y ago
  > The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C .... Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. What's the reach here of linters/address san/valgrind? Or a linter written specifically for the linux kernel? Require (error-path) tests? It feels excessive to plug another language if these are the main arguments? Are there any other arguments for using Rust? And even without any extra tools to guard against common mistakes, how much effort is solving those bug fixes anyway? Is it an order of magnitude larger than the cognitive load of learning a (not so easy!) language and context-switching continuously between them?
  • raverbashing 2y ago
    You can't valgrind kernel space Linters might be helpful, but I don't remember there being good free ones The problem here is simple: C is "too simple" for its own good and it puts undue cognitive burden on developers And those who reply with "skill issue" are the first to lose a finger on it
    • marhee 2y ago
      > You can't valgrind kernel space > Linters might be helpful, but I don't remember there being good free ones I should have Googled: https://www.kernel.org/doc/html/latest/dev-tools/ https://www.kernel.org/doc/html/latest/dev-tools/ So many tools here. Hard to believe these cannot come close to what Rust provides (if you put in the effort).
      • Avamander 2y ago
        Those solve a bunch of problems and can avoid a lot of issues if used properly, but it's time-consuming and cumbersome to say the least. Nowhere near as seamless or holistic as what Rust has to offer.
        • marhee 2y ago
• raverbashing 2y ago
  > The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.) C committee, are you listening? Hello? Hello? Bueller? (Unfortunately, if they are listening it is to make more changes on how compilers should take "creative licenses" in making developers shoot themselves in the foot)
  • TuxSH 2y ago
    > error path cleanups, forgetting to check error values, and use-after-free mistakes C++ (ideally, C++17 or 20 to have all the boilerplate-reducing tools) allows for all of that to be made, even in a freestanding environment. It's just that it's not enforced (flexibility is a good thing for evergreen/personal projects, less so for corporate codebases), and that the C++ committee seems to have weird priorities from what I've read (#embed drama, modules are a failure, concepts are being forced through despite concerns etc.) and treats freestanding/embedded as a second-class citizen.
• sim7c00 2y ago
  It's really all opinions what is better or worse, but i do respect the sentiment that there is some boundary, and on one side of the boundary, Rust makes a lot of sense, and the other side, Rust does not work at all. (managing global mutable resources). It weirds me out a bit there is even such discussions going on in projects like this. It seems obvious and proven at this point and if not that then atleast it should be obvious already for a long time that if you program within some large codebase or ecosystem, you are not the only voice, and you need to learn to collaborate with people with different views as you and make it work. I really don't like rust, hence instead of wanting to contribute to projects which will inadvertently lead to more and more rust code being brought in, i start my own projects, when i can be the only voice of reason and have my joys of making things segfault :>... Its quite simple. If like me you are stuobborn and unflexible, you are a lone wolf. accept it and move on to be happy :) rather than trying to piss against the wind of change.
  • ddtaylor 2y ago
    That's true. I often want to just make something cool and I don't want someone turning it into a research project basically because they like compilers.
    • tormeh 2y ago
      > Research project As if everything created after 1979 is a research project.
• NanoYohaneTSU 2y ago
  [flagged]
• Surac 2y ago
  perhaps someone can point me to a link where i can get information WHY it is so hard to call C from Rust or call into Rust code from C So i do not get the talk because i do not understand the issue.
  • _kb 2y ago
    FFI is inherently unsafe. That interfacing means wrapping the C API in a safe interface based on some set of invariants. If they don't hold, then you're in undefined behaviour territory. See https://doc.rust-lang.org/nomicon/ffi.html https://doc.rust-lang.org/nomicon/ffi.html for a fairly in-depth rundown.
  • pornel 2y ago
    It's not hard to just call C. Rust supports C ABI and there's tooling for converting between C headers and Rust interfaces. The challenging part is making a higher-level "safe" Rust API around the C API. Safe in the sense that it fully uses Rust's type system, lifetimes, destructors, etc. to uphold the safety guarantees that Rust gives and make it hard to misuse the API. But the objections about Rust in the kernel weren't really about the difficulty of writing the Rust code, but more broadly about having Rust there at all.
• vs4vijay 2y ago
  This might be a silly question, but why don't we have something like PR Gate pipelines that ensures it passes before being picked up by a maintainer?