24 ms·

So You Want to Rust the Linux Kernel?

240 points by lukastyrychtr 5y ago

phendrenad2 5y ago
I wonder how many people in this discussion have actually looked at kernel code. If you take an average chunk of kernel code, and try to reason about how to rewrite it in Rust, you'll note that the result looks surprisingly like C. Working with hardware registers, instructions, memory mapping, and trying to do all that with optimal runtime performance puts a lot of constraints on you. Rust is all about memory safety. Well, what does it mean when the entire memory map is not only accessible to you, but DEFINED by you?
carom 5y ago
I couldn't back out of this page on mobile.
- tkzed49 5y ago
  Works fine for me on Chrome
  - Ensorceled 5y ago
    Is this an ad for Chrome or are you disputing the comment?
    - tkzed49 5y ago
      I realize chrome is a sensitive subject here, but I'm just narrowing down the problem :)
  - lbayes 5y ago
    Also hit the back button trap with Firefox on Android. Ew
- pedrocr 5y ago
  If it's Firefox on Android long-pressing the back button gives you a history list that allows going back. It's a bug that happens in many sites, where the history gets a bunch of duplicate entries of the current page for some reason.
  - jve 5y ago
    I think it is not a bug but abuse of history. Especially when landing on some shady site via google - good luck backing out. Right click on "BACK" helps as it shows the history. Sometimes with MANY duplicate entries.
  - sen 5y ago
    It’s not a bug, a huge amounts of sites are doing this now, or hijacking the back button completely to send you to an ad or their homepage.
    - pedrocr 5y ago
      There are probably sites doing this maliciously but the cases I've seen are weird things like only some subreddits and even then not always. I suspect there's a bug somewhere in a commonly used web framework or in Firefox mobile itself. This site for example doesn't have the issue in the desktop version of the site, only the mobile one.
- napsterbr 5y ago
  Me too. Looks like I got redirected two or three times there. Not sure if it's a bug or marketing crap.
TacticalCoder 5y ago
> On the other hand, might the rumored sudden merge of the ksmdb driver (https://lwn.net/Articles/871098/ https://lwn.net/Articles/871098/) have been due to the implicit threat of its being rewritten in Rust? That links to a message saying this: > "ksmbd was then merged unbeknownst to me and my worries confirmed to be true as some out-of-bounds bugs (which are impossible in Rust) surfaced immediately." Sad.
- josefx 5y ago
  I would like a link to the bugs in question. The only bugs I found have a long email chain with people being surprised that the kernel module even passed any tests at all, with extensive changes needed to fix logic issues for the path conversion code. The devs. even added an unload reload cycle to the tests because the module was in a bad enough state that it wouldn't consistently run over several iterations. I wouldn't be surprised if they would simply turn to unsafe if they had to write it in Rust, errors are apparently to be worked around not fixed. [1] [1]https://lore.kernel.org/lkml/CAH2r5mvu5wTcgoR-EeXLcoZOvhEiMR0Lfmwt6gd1J1wvtTLDHA@mail.gmail.com/T/#u https://lore.kernel.org/lkml/CAH2r5mvu5wTcgoR-EeXLcoZOvhEiMR... edit: the last part of my comment may be a bit over the top, but I think the quality issues at the language level are just the tip of the iceberg for this module.
  - Measter 5y ago
    > I wouldn't be surprised if they would simply turn to unsafe if they had to write it in Rust, errors are apparently to be worked around not fixed. They probably would. But it's easier to find usages of unsafe through grep or the like than it is with C because Rust's syntax and requirement of marking unsafe make it easier to find. To use one of my own codebases for example, I can look at the instances of the following regex patterns: * "\bfn\b" (function declarations), 138 matches. * "\bunsafe\s+fn\b" or "\bunsafe\s+extern\b" (unsafe function declarations), 23 total. * "\bunsafe\s*\{" (opening an unsafe block), 41 matches. * "\bunsafe\s+impl" (unsafe trait implementation), 0 matches. We can also look at the total lines of code written (2269), and ask if this these numbers feel reasonable for what it's doing. Obviously that will require familiarity with Rust, what's being implemented, and the expected amount of unsafe based on previous usage in the kernel, but it would at least give an overall feel. And, of course, if you want to examine any of them, you know exactly where they are.
pharmakom 5y ago
Genuine question for Rust programmers: Memory safety without GC is a big selling point of Rust. However, sometimes your program’s ownership model does not fit with what the Rust borrow-checker can verify. Not to worry, just use “unsafe”. But if “unsafe” is used, can we still claim that Rust code is safe?
- Gaelan 5y ago
  Generally, the idea is that you use a small amount of unsafe code to build a safe abstraction to do what you need, then use that abstraction in many places. So now you only have a few unsafe sections you have to verify for correctness, instead of the entire program like you'd need in C/C++.
- rapsey 5y ago
  > However, sometimes your program’s ownership model does not fit with what the Rust borrow-checker can verify. This tends to be a beginner issue for c/c++ programmers. 99% of the time you just need to rethink your design into something better.
- nchi3 5y ago
  No, but it makes it explicit regarding what's unsafe, so that you'll more easily know where to put resources to make the unsafe code as bomb proof as possible. In C that's 100% of the code, in Rust you can keep it to a low percentage.
- foldr 5y ago
  Ideally the unsafe parts are restricted to modules which have been proven safe to an appropriate degree of confidence. ('Unsafe' in Rust really means 'not guaranteed by the type system to be safe', so it's not a contradiction in terms to show that 'unsafe' code is safe.) One might respond that you can do the same kind of modularization in C++. However, I think a Rust advocate would argue that it's much more difficult in practice to modularize unsafe code in C++ to the same degree, since unsafe idioms are deeply embedded in the language and library ecosystem.
- dochtman 5y ago
  unsafe code blocks are required to uphold the invariants of the safe Rust code surrounding it. So yes, if you fail to uphold those invariants (and that's proven to be pretty tricky), your program is not safe. My experience is that you hardly ever need unsafe Rust code. If your ownership model doesn't the borrow checker, there are of course also other avenues like ref counts or even an actual garbage collecter (which you can chose to apply only to values whose ownership situation is not aligned with the stack). Only when those options are unable to give you the performance you want you'll need to reach for unsafe code. Other scenarios where you'll need unsafe might include things like SIMD (although safe wrappers exist) or FFI, but hopefully we'll evolve the Rust ecosystem over time to concentrate the unsafe code in a few places by building abstractions, where they are thoroughly reviewed and well tested.
xvilka 5y ago
Another approach would be to go all in into improving the kernel [1] completely written in Rust, like in RedoxOS[2]. [1] https://gitlab.redox-os.org/redox-os/kernel https://gitlab.redox-os.org/redox-os/kernel [2] https://www.redox-os.org/ https://www.redox-os.org/
- 5e92cb50239222b 5y ago
  One of the main value propositions of Linux compared to any such alternative are thousands of drivers for almost any device that you can find on the market. Unless you find somebody willing to port them, I see very little practical sense in doing this (unless your goal is to have fun).
  - Const-me 5y ago
    Moreover, for many critically important pieces of hardware, such as ARM Mali GPUs, the drivers are only available for Linux and Android.
  - bo0tzz 5y ago
    Why not include support for running those 'legacy' C drivers in that new Rust kernel? Sure, you'd be giving up some of the memory guarantees, but that's no different from when you include some Rust into the current kernel.
    - rini17 5y ago
      There's no stable ABI for drivers. So much even Linux kernel itself isn't compatible with its drivers without their constant maintenance.
      - rcxdude 5y ago
        There's not even a stable API for drivers. The interfaces they use get changed and rewritten all the time.
        5y ago
encryptluks2 5y ago
I'm almost certain at this point, Linus will eventually kill the idea of Rust in the kernel. The toxic culture of Rust developers will eventually ruin what was once good about Linux.
- franga2000 5y ago
  > The toxic culture of Rust developers What a strong and damning claim, it would be a shame if it were left entirely unsubstantiated...
  - throwaway432242 5y ago
    Not the OP, but here's an explanation anyway: the Rust community is full of superficially kind and polite language, enforced ruthlessly, that masks a high level of politics, intrigue, and backstabbing. The problem is worsened by people being unable to talk about it in the open due to the Rust community's enforced superficial politeness --- it's against the rules, you see, to accuse someone who's using such helpful and kind language of doing something wrong. Example: see the drama surrounding https://news.ycombinator.com/item?id=28513130 https://news.ycombinator.com/item?id=28513130 The Linux kernel people are completely different. They're direct, aggressive, and have arguments directly, out in the open. Linus will call you an idiot in public, which is a big no-no in "nice" places like Rust, but if you fix whatever it is that's making him call you an idiot, Linus will then take your code and think nothing more about the incident. By contrast, in Rust-land, disputes might simmer forever because nobody is allowed to by "mean" and bring them out into the open. Things will just mysteriously not happen for you and you'll get more and more frustrated that nothing seems to be making any sense. In other words: Linux has an old-school hacker culture, and Rust has the culture of a college campus. People used to the Rust style think of the Linux community as a bunch of toxic aggressive assholes. People used to the Linux style think of the Rust people as a bunch of toxic passive-aggressive assholes. (I personally much prefer the Linux style.)
    - pdimitar 5y ago
      Classic example of filter bubble. I've seen what you describe about the Rust community in many others -- and only occasionally in the Rust one. Super strange comment, your one. Goes into "Rust devs can't take criticism" land and has no leg to stand on at that.
indeyets 5y ago
There's previous discussion on reddit https://www.reddit.com/r/rust/comments/pzo1v9/so_you_want_to_rust_the_linux_kernel/ https://www.reddit.com/r/rust/comments/pzo1v9/so_you_want_to... with important points
quotemstr 5y ago
Reading through the descriptions of the fast and sophisticated memory synchronization techniques in Linux that Rust cannot express in safe code, I have to wonder how many optimization opportunities would have gone undiscovered, forever, if the kernel had been written in Rust from the start. Language shapes how we think about the world. Ideas that are hard to describe in the language of the mind are hard to imagine in the first place. What potential avenues for improvement might we lose by shifting computing to safe but constricting languages like Rust?
- kaba0 5y ago
  Rust is not confining at all, you always have an escape hatch through unsafe, but even without that, programs that fail to compile would mostly all be faulty ones.
  - quotemstr 5y ago
    > Rust is not confining at all, Yes, it is, and the linked blog posts talk about how. Did you read them? My point isn't that some ideas can't be expressed in Rust. It's true that with sufficient effort, Rust can express anything. My point is that some ideas are harder and more awkward to express in Rust compared to C, and that as a result, people might have been less likely to invent those difficult-to-imagine ideas if they'd been working in Rust and not C. I'm basically arguing for the "weak" variant of the Sapir-Whorf hypothesis as applied to programming languages. The weak form of Sapir-Whorf is obviously true with respect to human languages. To the responses below: Yes, it's true that Rust's higher level of abstraction allows for optimizations difficult to express in C. It's worth pointing out that C++ has similar expressiveness but doesn't constrain access to the machine in the same way. > Sure some things might be harder to express in Rust, but the tradeoff is well worth it. You're missing my point. For some types of code, the safety Rust provides might be "worth it". I'm just suggesting that there really are performance-enhancing techniques that would have gone uninvented in a Rust-only world. You seem to be agreeing with me and adding on top that we don't need that stinking performance anyway, so nothing I said presents a problem. Can you see how someone might disagree with that perspective?
volta83 5y ago
> Given that DEC Alpha famously had difficulty with RCU, it is only reasonable to ask how Rust will do with it. > Including some wild speculation about how Rust's ownership model might be generalized I recommend starting with the latests post in the series and the conclusions(https://paulmck.livejournal.com/64209.html https://paulmck.livejournal.com/64209.html and https://paulmck.livejournal.com/65056.html https://paulmck.livejournal.com/65056.html). From the snippets at the beginning, it looks like the author documented how they started learning about how to solve these problems in Rust, and it does not take too long until the comment section starts pointing the author at crossbeam-rs, GhostCell, etc. which only start appearing in the series in the last couple of sections. Learning Rust by implementing a linked-list is pretty hard, but "Learning Rust by implementing RCU" has to be, by far, the hardest way to learn Rust that I know of. Kudos to the author for pushing through this so quickly and thoroguly. The posts are all excellent. I wish the author would go a little bit more into crossbeam-rs. One thing the author does not consider, is that a safe Rust interface to RCU is essentially a "proof of correctness" for RCU, i.e., it proves that using RCU via that interface cannot introduce undefined behavior. (Or maybe more technically, the contracts on the correctness of unsafe code within the safe wrapper provide a potentially incorrect "proof" of this). AFAIK no such correctness proof for the C APIs exists (there are a couple of linters that catch some issues, but there is no proof that say that if you stick by those warnings your code is UB free). The author seems to be assuming that the C APIs to RCU have been proved correct, which AFAIK is incorrect, and by ignoring the safe Rust APIs to RCU, the author is missing out on potentially finding issues on the correctness of the C APIs that Rust would discover. Basically, the question: "Can we expose Linux RCU apis to Rust?" is definetly worth asking, but the question "Can Rust prove Linux RCU APIs correct?" is much more interesting. If it can't, then why not? The fact that we have such proofs for other RCU and hazard pointers APIs in Rust shows that this is at least possible in general. And if Linux RCU can't be exposed in safe Rust, precisely understanding why would definitely be illuminating (Can Linux RCU be proven correct outside Rust, but not in Rust? Or maybe does Linux RCU APIs can actually be proven incorrect by Rust?).
- dbrgn 5y ago
  Note: If someone wants to learn Rust by implementing linked lists, then https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/ is a must-read :)
tgz 5y ago
Yes, I want!
darthrupert 5y ago
Rust in core Linux would probably be a horrible idea, given all the complexities of the language. For drivers it could be fine. But so could many other languages. So why Rust?
- ajsnigrutin 5y ago
  This is HN.... every day there are articles about "$(this old existing software) written in $(language of the week)" $(language of the week) changes, and people continue using the old software, written in c/c++/...
  - kobalsky 5y ago
    except c++ is not welcome on the linux kernel. torvalds said recently: “Probably next year, we’ll start seeing some first intrepid modules being written in Rust, and maybe being integrated in the mainline kernel.” [1] the rust community is a bit over-excited, but if you can look past that, there's substance in the hype. [1] https://thenewstack.io/linus-torvalds-on-community-rust-and-linuxs-longevity/ https://thenewstack.io/linus-torvalds-on-community-rust-and-...
  - pdimitar 5y ago
    > $(language of the week) Rust is 10 years old. See, such knee-jerk reactions are exactly why many people have trouble taking the anti-Rust arguers seriously. It's like you people defend religion or something. How about we stick to facts?
- adwn 5y ago
  > Rust in core Linux would probably be a horrible idea, given all the complexities of the language. C is a very complex language as well. It's just that when you're not aware of all the complexities in Rust, the compiler will refuse to compile; in C, you'll get a security vulnerability or weird crashes at runtime. Yes, this is a generalization, but only slightly. C is deceptively simple – its complexities are well hidden.
  - bcrosby95 5y ago
qwerty456127 5y ago
What, beyond the device drivers, even is so valuable in the Linux kernel that we would want to add Rust to it rather than develop a new kernel from scratch in Rust?
- philipswood 5y ago
  Is that a hint of Pythonic hubris?
  - qwerty456127 5y ago
    It's the decades of perception of the Linux kernel as an insanely bloated pile of legacy code in a legacy language (I would rather go modern C++ the way SerenityOS did, not necessarily even Rust) + the driver problem (new OSes have little option besides borrowing what little there is in NetBSD which seemingly has the best driver model) + optimism caused by numerous alternative OSes projects + plus some functional programmer hubris. I have tried quite a number of alternative OSes and the only thing I can see a problem with are hardware drivers.
    - ilaksh 5y ago
      Maybe a new OS project with a focus on directly funding things like driver ports. Funnelling donations to something like Ethlance.
- dboreham 5y ago
  Because at best that new kernel would be as popular as BSD?
  - qwerty456127 5y ago
    Hm. Okay. Why not? I would even prefer a world of less popular kernels to one single kernel everybody uses. In fact some "default Linux" with systemd et. al. becoming too popular already seems worrying.
  - ezekiel68 5y ago
b20000 5y ago
I don't want rust in the kernel. As a small time developer making a hardware product, the investment to understand the kernel and how to build drivers is already huge. I have no interest in learning rust, and it will make it harder for people with limited resources to use linux in their projects.
- Shared404 5y ago
  To be honest, I don't think Linux being the "One True Kernel" is really worthwhile, and the benefits of adding Rust to the kernel outweigh the downsides. There are plenty of other kernels available for embedded work, and my understanding of Rust in the Linux kernel is that it's mostly drivers, which seems like it would be optional for your use case. That said, I've not done much embedded, I may be misunderstanding something.
  - SavantIdiot 5y ago
    Rust is a language that forces you to do things in a way that makes code more robust at the cost of a little upfront thought and inconvenience. The parent comment is complaining that Rust will make kernel dev too hard? Are they joking? It is already complicated. I would rather see a more formally constructed language used for the kernel than risk adding more C-related bugs.
    - shadowgovt 5y ago
      > It is already complicated And specifically, one of the ways in which it is complicated is that it's mostly done in a language that doesn't natively enforce memory-safe constructs, forcing developers to walk a best-practices and tooling tightrope to avoid writing code that breaks.
      - SavantIdiot 5y ago
        Why the heck is this comment grey?! At least reply and explain where they are wrong?
      - 5y ago
timz67 5y ago
In the immortal words of GEOTUS, "Everything woke turns to shit."
timz67 5y ago
This is just a political assault by the wokistan to infiltrate and dominate all aspects of software. They already started this a long time ago with the "Linux Foundation". Anything with 'foundation' in it is meant to exert political control by those who can't code. They are very up front about this too - go look at Steve's twitter. He 100% supports violence to obtain control.
Animats 5y ago
I wish someone would rewrite the QNX kernel, which is tiny, in Rust. No one seems to have saved a copy of the sources before they went proprietary with the Blackberry acquisition.
- atombender 5y ago
  QNX was never open source, so I'm not sure how that would have been legally feasible. It's a shame that a high-quality microkernel OS like QNX has never been made, though, except as proprietary commercial products. QNX has by most accounts been quite successful (the , but it's still a niche product.
  - discreteevent 5y ago
    Fuchsia might do it.
  - Animats 5y ago
    For a few years, after the first acquisition but before the second by Blackberry, the source was online. Not as free software, but you could look at it. I used to tell the QNX sales rep, "You worry about your product being pirated. Worry more about it being ignored." The major customers are big industrial firms and auto companies, and if they use it, you can find them. Besides, they want the support contract.
aliswe 5y ago
This author is very intelligent, well versed and wonderfully dry at the same time as being slightly amusing: > For all of these references, I give a big "Thank You!!!" to my co-authors. ... > This pointer is now a "zombie pointer" that has come back from the dead, or that has at least come to have a more entertaining form of invalidity. ... > Furthermore, even given unanticipated universal acclamation of Rust within the Linux kernel community combined with equally unanticipated advances in C-to-Rust translation capabilities, a significant fraction of the existing tens of millions of lines of Linux-kernel C code will persist for some time to come. and his parting words, not that he is negative or pessimistic about Rust but rather highlighting some unsolved challenges and their possible solutions: > In short, choose wisely and be very careful what you wish for! ;-)
csense 5y ago
I can't remember the last time I went to a Livejournal site. Maybe sometime around 2003?

240 points by lukastyrychtr 5y ago

I wonder how many people in this discussion have actually looked at kernel code. If you take an average chunk of kernel code, and try to reason about how to rewrite it in Rust, you'll note that the result looks surprisingly like C. Working with hardware registers, instructions, memory mapping, and trying to do all that with optimal runtime performance puts a lot of constraints on you. Rust is all about memory safety. Well, what does it mean when the entire memory map is not only accessible to you, but DEFINED by you?

carom 5y ago

I couldn't back out of this page on mobile.

tkzed49 5y ago
Works fine for me on Chrome
- Ensorceled 5y ago
  Is this an ad for Chrome or are you disputing the comment?
  - tkzed49 5y ago
    I realize chrome is a sensitive subject here, but I'm just narrowing down the problem :)
- lbayes 5y ago
  Also hit the back button trap with Firefox on Android. Ew
pedrocr 5y ago
If it's Firefox on Android long-pressing the back button gives you a history list that allows going back. It's a bug that happens in many sites, where the history gets a bunch of duplicate entries of the current page for some reason.
- jve 5y ago
  I think it is not a bug but abuse of history. Especially when landing on some shady site via google - good luck backing out. Right click on "BACK" helps as it shows the history. Sometimes with MANY duplicate entries.
- sen 5y ago
  It’s not a bug, a huge amounts of sites are doing this now, or hijacking the back button completely to send you to an ad or their homepage.
  - pedrocr 5y ago
    There are probably sites doing this maliciously but the cases I've seen are weird things like only some subreddits and even then not always. I suspect there's a bug somewhere in a commonly used web framework or in Firefox mobile itself. This site for example doesn't have the issue in the desktop version of the site, only the mobile one.
napsterbr 5y ago
Me too. Looks like I got redirected two or three times there. Not sure if it's a bug or marketing crap.

TacticalCoder 5y ago

> On the other hand, might the rumored sudden merge of the ksmdb driver (https://lwn.net/Articles/871098/ https://lwn.net/Articles/871098/) have been due to the implicit threat of its being rewritten in Rust? That links to a message saying this: > "ksmbd was then merged unbeknownst to me and my worries confirmed to be true as some out-of-bounds bugs (which are impossible in Rust) surfaced immediately." Sad.

josefx 5y ago
I would like a link to the bugs in question. The only bugs I found have a long email chain with people being surprised that the kernel module even passed any tests at all, with extensive changes needed to fix logic issues for the path conversion code. The devs. even added an unload reload cycle to the tests because the module was in a bad enough state that it wouldn't consistently run over several iterations. I wouldn't be surprised if they would simply turn to unsafe if they had to write it in Rust, errors are apparently to be worked around not fixed. [1] [1]https://lore.kernel.org/lkml/CAH2r5mvu5wTcgoR-EeXLcoZOvhEiMR0Lfmwt6gd1J1wvtTLDHA@mail.gmail.com/T/#u https://lore.kernel.org/lkml/CAH2r5mvu5wTcgoR-EeXLcoZOvhEiMR... edit: the last part of my comment may be a bit over the top, but I think the quality issues at the language level are just the tip of the iceberg for this module.
- Measter 5y ago
  > I wouldn't be surprised if they would simply turn to unsafe if they had to write it in Rust, errors are apparently to be worked around not fixed. They probably would. But it's easier to find usages of unsafe through grep or the like than it is with C because Rust's syntax and requirement of marking unsafe make it easier to find. To use one of my own codebases for example, I can look at the instances of the following regex patterns: * "\bfn\b" (function declarations), 138 matches. * "\bunsafe\s+fn\b" or "\bunsafe\s+extern\b" (unsafe function declarations), 23 total. * "\bunsafe\s*\{" (opening an unsafe block), 41 matches. * "\bunsafe\s+impl" (unsafe trait implementation), 0 matches. We can also look at the total lines of code written (2269), and ask if this these numbers feel reasonable for what it's doing. Obviously that will require familiarity with Rust, what's being implemented, and the expected amount of unsafe based on previous usage in the kernel, but it would at least give an overall feel. And, of course, if you want to examine any of them, you know exactly where they are.

pharmakom 5y ago

Genuine question for Rust programmers: Memory safety without GC is a big selling point of Rust. However, sometimes your program’s ownership model does not fit with what the Rust borrow-checker can verify. Not to worry, just use “unsafe”. But if “unsafe” is used, can we still claim that Rust code is safe?

Gaelan 5y ago
Generally, the idea is that you use a small amount of unsafe code to build a safe abstraction to do what you need, then use that abstraction in many places. So now you only have a few unsafe sections you have to verify for correctness, instead of the entire program like you'd need in C/C++.
rapsey 5y ago
> However, sometimes your program’s ownership model does not fit with what the Rust borrow-checker can verify. This tends to be a beginner issue for c/c++ programmers. 99% of the time you just need to rethink your design into something better.
nchi3 5y ago
No, but it makes it explicit regarding what's unsafe, so that you'll more easily know where to put resources to make the unsafe code as bomb proof as possible. In C that's 100% of the code, in Rust you can keep it to a low percentage.
foldr 5y ago
Ideally the unsafe parts are restricted to modules which have been proven safe to an appropriate degree of confidence. ('Unsafe' in Rust really means 'not guaranteed by the type system to be safe', so it's not a contradiction in terms to show that 'unsafe' code is safe.) One might respond that you can do the same kind of modularization in C++. However, I think a Rust advocate would argue that it's much more difficult in practice to modularize unsafe code in C++ to the same degree, since unsafe idioms are deeply embedded in the language and library ecosystem.
dochtman 5y ago
unsafe code blocks are required to uphold the invariants of the safe Rust code surrounding it. So yes, if you fail to uphold those invariants (and that's proven to be pretty tricky), your program is not safe. My experience is that you hardly ever need unsafe Rust code. If your ownership model doesn't the borrow checker, there are of course also other avenues like ref counts or even an actual garbage collecter (which you can chose to apply only to values whose ownership situation is not aligned with the stack). Only when those options are unable to give you the performance you want you'll need to reach for unsafe code. Other scenarios where you'll need unsafe might include things like SIMD (although safe wrappers exist) or FFI, but hopefully we'll evolve the Rust ecosystem over time to concentrate the unsafe code in a few places by building abstractions, where they are thoroughly reviewed and well tested.

xvilka 5y ago

Another approach would be to go all in into improving the kernel [1] completely written in Rust, like in RedoxOS[2]. [1] https://gitlab.redox-os.org/redox-os/kernel https://gitlab.redox-os.org/redox-os/kernel [2] https://www.redox-os.org/ https://www.redox-os.org/

5e92cb50239222b 5y ago
One of the main value propositions of Linux compared to any such alternative are thousands of drivers for almost any device that you can find on the market. Unless you find somebody willing to port them, I see very little practical sense in doing this (unless your goal is to have fun).
- Const-me 5y ago
  Moreover, for many critically important pieces of hardware, such as ARM Mali GPUs, the drivers are only available for Linux and Android.
- bo0tzz 5y ago
  Why not include support for running those 'legacy' C drivers in that new Rust kernel? Sure, you'd be giving up some of the memory guarantees, but that's no different from when you include some Rust into the current kernel.
  - rini17 5y ago
    There's no stable ABI for drivers. So much even Linux kernel itself isn't compatible with its drivers without their constant maintenance.
    - rcxdude 5y ago
      There's not even a stable API for drivers. The interfaces they use get changed and rewritten all the time.
      - 5y ago

encryptluks2 5y ago

I'm almost certain at this point, Linus will eventually kill the idea of Rust in the kernel. The toxic culture of Rust developers will eventually ruin what was once good about Linux.

franga2000 5y ago
> The toxic culture of Rust developers What a strong and damning claim, it would be a shame if it were left entirely unsubstantiated...
- throwaway432242 5y ago
  Not the OP, but here's an explanation anyway: the Rust community is full of superficially kind and polite language, enforced ruthlessly, that masks a high level of politics, intrigue, and backstabbing. The problem is worsened by people being unable to talk about it in the open due to the Rust community's enforced superficial politeness --- it's against the rules, you see, to accuse someone who's using such helpful and kind language of doing something wrong. Example: see the drama surrounding https://news.ycombinator.com/item?id=28513130 https://news.ycombinator.com/item?id=28513130 The Linux kernel people are completely different. They're direct, aggressive, and have arguments directly, out in the open. Linus will call you an idiot in public, which is a big no-no in "nice" places like Rust, but if you fix whatever it is that's making him call you an idiot, Linus will then take your code and think nothing more about the incident. By contrast, in Rust-land, disputes might simmer forever because nobody is allowed to by "mean" and bring them out into the open. Things will just mysteriously not happen for you and you'll get more and more frustrated that nothing seems to be making any sense. In other words: Linux has an old-school hacker culture, and Rust has the culture of a college campus. People used to the Rust style think of the Linux community as a bunch of toxic aggressive assholes. People used to the Linux style think of the Rust people as a bunch of toxic passive-aggressive assholes. (I personally much prefer the Linux style.)
  - pdimitar 5y ago
    Classic example of filter bubble. I've seen what you describe about the Rust community in many others -- and only occasionally in the Rust one. Super strange comment, your one. Goes into "Rust devs can't take criticism" land and has no leg to stand on at that.

indeyets 5y ago

There's previous discussion on reddit https://www.reddit.com/r/rust/comments/pzo1v9/so_you_want_to_rust_the_linux_kernel/ https://www.reddit.com/r/rust/comments/pzo1v9/so_you_want_to... with important points

quotemstr 5y ago

Reading through the descriptions of the fast and sophisticated memory synchronization techniques in Linux that Rust cannot express in safe code, I have to wonder how many optimization opportunities would have gone undiscovered, forever, if the kernel had been written in Rust from the start. Language shapes how we think about the world. Ideas that are hard to describe in the language of the mind are hard to imagine in the first place. What potential avenues for improvement might we lose by shifting computing to safe but constricting languages like Rust?

kaba0 5y ago
Rust is not confining at all, you always have an escape hatch through unsafe, but even without that, programs that fail to compile would mostly all be faulty ones.
- quotemstr 5y ago
  > Rust is not confining at all, Yes, it is, and the linked blog posts talk about how. Did you read them? My point isn't that some ideas can't be expressed in Rust. It's true that with sufficient effort, Rust can express anything. My point is that some ideas are harder and more awkward to express in Rust compared to C, and that as a result, people might have been less likely to invent those difficult-to-imagine ideas if they'd been working in Rust and not C. I'm basically arguing for the "weak" variant of the Sapir-Whorf hypothesis as applied to programming languages. The weak form of Sapir-Whorf is obviously true with respect to human languages. To the responses below: Yes, it's true that Rust's higher level of abstraction allows for optimizations difficult to express in C. It's worth pointing out that C++ has similar expressiveness but doesn't constrain access to the machine in the same way. > Sure some things might be harder to express in Rust, but the tradeoff is well worth it. You're missing my point. For some types of code, the safety Rust provides might be "worth it". I'm just suggesting that there really are performance-enhancing techniques that would have gone uninvented in a Rust-only world. You seem to be agreeing with me and adding on top that we don't need that stinking performance anyway, so nothing I said presents a problem. Can you see how someone might disagree with that perspective?

volta83 5y ago

> Given that DEC Alpha famously had difficulty with RCU, it is only reasonable to ask how Rust will do with it. > Including some wild speculation about how Rust's ownership model might be generalized I recommend starting with the latests post in the series and the conclusions(https://paulmck.livejournal.com/64209.html https://paulmck.livejournal.com/64209.html and https://paulmck.livejournal.com/65056.html https://paulmck.livejournal.com/65056.html). From the snippets at the beginning, it looks like the author documented how they started learning about how to solve these problems in Rust, and it does not take too long until the comment section starts pointing the author at crossbeam-rs, GhostCell, etc. which only start appearing in the series in the last couple of sections. Learning Rust by implementing a linked-list is pretty hard, but "Learning Rust by implementing RCU" has to be, by far, the hardest way to learn Rust that I know of. Kudos to the author for pushing through this so quickly and thoroguly. The posts are all excellent. I wish the author would go a little bit more into crossbeam-rs. One thing the author does not consider, is that a safe Rust interface to RCU is essentially a "proof of correctness" for RCU, i.e., it proves that using RCU via that interface cannot introduce undefined behavior. (Or maybe more technically, the contracts on the correctness of unsafe code within the safe wrapper provide a potentially incorrect "proof" of this). AFAIK no such correctness proof for the C APIs exists (there are a couple of linters that catch some issues, but there is no proof that say that if you stick by those warnings your code is UB free). The author seems to be assuming that the C APIs to RCU have been proved correct, which AFAIK is incorrect, and by ignoring the safe Rust APIs to RCU, the author is missing out on potentially finding issues on the correctness of the C APIs that Rust would discover. Basically, the question: "Can we expose Linux RCU apis to Rust?" is definetly worth asking, but the question "Can Rust prove Linux RCU APIs correct?" is much more interesting. If it can't, then why not? The fact that we have such proofs for other RCU and hazard pointers APIs in Rust shows that this is at least possible in general. And if Linux RCU can't be exposed in safe Rust, precisely understanding why would definitely be illuminating (Can Linux RCU be proven correct outside Rust, but not in Rust? Or maybe does Linux RCU APIs can actually be proven incorrect by Rust?).

dbrgn 5y ago
Note: If someone wants to learn Rust by implementing linked lists, then https://rust-unofficial.github.io/too-many-lists/ https://rust-unofficial.github.io/too-many-lists/ is a must-read :)

tgz 5y ago

Yes, I want!

darthrupert 5y ago

Rust in core Linux would probably be a horrible idea, given all the complexities of the language. For drivers it could be fine. But so could many other languages. So why Rust?

ajsnigrutin 5y ago
This is HN.... every day there are articles about "$(this old existing software) written in $(language of the week)" $(language of the week) changes, and people continue using the old software, written in c/c++/...
- kobalsky 5y ago
  except c++ is not welcome on the linux kernel. torvalds said recently: “Probably next year, we’ll start seeing some first intrepid modules being written in Rust, and maybe being integrated in the mainline kernel.” [1] the rust community is a bit over-excited, but if you can look past that, there's substance in the hype. [1] https://thenewstack.io/linus-torvalds-on-community-rust-and-linuxs-longevity/ https://thenewstack.io/linus-torvalds-on-community-rust-and-...
- pdimitar 5y ago
  > $(language of the week) Rust is 10 years old. See, such knee-jerk reactions are exactly why many people have trouble taking the anti-Rust arguers seriously. It's like you people defend religion or something. How about we stick to facts?
adwn 5y ago
> Rust in core Linux would probably be a horrible idea, given all the complexities of the language. C is a very complex language as well. It's just that when you're not aware of all the complexities in Rust, the compiler will refuse to compile; in C, you'll get a security vulnerability or weird crashes at runtime. Yes, this is a generalization, but only slightly. C is deceptively simple – its complexities are well hidden.
- bcrosby95 5y ago

qwerty456127 5y ago

What, beyond the device drivers, even is so valuable in the Linux kernel that we would want to add Rust to it rather than develop a new kernel from scratch in Rust?

philipswood 5y ago
Is that a hint of Pythonic hubris?
- qwerty456127 5y ago
  It's the decades of perception of the Linux kernel as an insanely bloated pile of legacy code in a legacy language (I would rather go modern C++ the way SerenityOS did, not necessarily even Rust) + the driver problem (new OSes have little option besides borrowing what little there is in NetBSD which seemingly has the best driver model) + optimism caused by numerous alternative OSes projects + plus some functional programmer hubris. I have tried quite a number of alternative OSes and the only thing I can see a problem with are hardware drivers.
  - ilaksh 5y ago
    Maybe a new OS project with a focus on directly funding things like driver ports. Funnelling donations to something like Ethlance.
dboreham 5y ago
Because at best that new kernel would be as popular as BSD?
- qwerty456127 5y ago
  Hm. Okay. Why not? I would even prefer a world of less popular kernels to one single kernel everybody uses. In fact some "default Linux" with systemd et. al. becoming too popular already seems worrying.
- ezekiel68 5y ago

b20000 5y ago

I don't want rust in the kernel. As a small time developer making a hardware product, the investment to understand the kernel and how to build drivers is already huge. I have no interest in learning rust, and it will make it harder for people with limited resources to use linux in their projects.

Shared404 5y ago
To be honest, I don't think Linux being the "One True Kernel" is really worthwhile, and the benefits of adding Rust to the kernel outweigh the downsides. There are plenty of other kernels available for embedded work, and my understanding of Rust in the Linux kernel is that it's mostly drivers, which seems like it would be optional for your use case. That said, I've not done much embedded, I may be misunderstanding something.
- SavantIdiot 5y ago
  Rust is a language that forces you to do things in a way that makes code more robust at the cost of a little upfront thought and inconvenience. The parent comment is complaining that Rust will make kernel dev too hard? Are they joking? It is already complicated. I would rather see a more formally constructed language used for the kernel than risk adding more C-related bugs.
  - shadowgovt 5y ago
    > It is already complicated And specifically, one of the ways in which it is complicated is that it's mostly done in a language that doesn't natively enforce memory-safe constructs, forcing developers to walk a best-practices and tooling tightrope to avoid writing code that breaks.
    - SavantIdiot 5y ago
      Why the heck is this comment grey?! At least reply and explain where they are wrong?
    - 5y ago

timz67 5y ago

In the immortal words of GEOTUS, "Everything woke turns to shit."

timz67 5y ago

This is just a political assault by the wokistan to infiltrate and dominate all aspects of software. They already started this a long time ago with the "Linux Foundation". Anything with 'foundation' in it is meant to exert political control by those who can't code. They are very up front about this too - go look at Steve's twitter. He 100% supports violence to obtain control.

Animats 5y ago

I wish someone would rewrite the QNX kernel, which is tiny, in Rust. No one seems to have saved a copy of the sources before they went proprietary with the Blackberry acquisition.

atombender 5y ago
QNX was never open source, so I'm not sure how that would have been legally feasible. It's a shame that a high-quality microkernel OS like QNX has never been made, though, except as proprietary commercial products. QNX has by most accounts been quite successful (the , but it's still a niche product.
- discreteevent 5y ago
  Fuchsia might do it.
- Animats 5y ago
  For a few years, after the first acquisition but before the second by Blackberry, the source was online. Not as free software, but you could look at it. I used to tell the QNX sales rep, "You worry about your product being pirated. Worry more about it being ignored." The major customers are big industrial firms and auto companies, and if they use it, you can find them. Besides, they want the support contract.

aliswe 5y ago

This author is very intelligent, well versed and wonderfully dry at the same time as being slightly amusing: > For all of these references, I give a big "Thank You!!!" to my co-authors. ... > This pointer is now a "zombie pointer" that has come back from the dead, or that has at least come to have a more entertaining form of invalidity. ... > Furthermore, even given unanticipated universal acclamation of Rust within the Linux kernel community combined with equally unanticipated advances in C-to-Rust translation capabilities, a significant fraction of the existing tens of millions of lines of Linux-kernel C code will persist for some time to come. and his parting words, not that he is negative or pessimistic about Rust but rather highlighting some unsolved challenges and their possible solutions: > In short, choose wisely and be very careful what you wish for! ;-)

csense 5y ago

I can't remember the last time I went to a Livejournal site. Maybe sometime around 2003?