5 ms·

Funny you ask, I was wondering the same thing last night so I went through the rust-for-linux mailing list archive. This thread is pretty telling: https://lore

Funny you ask, I was wondering the same thing last night so I went through the rust-for-linux mailing list archive. This thread is pretty telling: https://lore.kernel.org/rust-for-linux/bddea099-4468-4f96-2e06-2b207b608485@usi.ch/ https://lore.kernel.org/rust-for-linux/bddea099-4468-4f96-2e... https://lore.kernel.org/rust-for-linux/c61a60ef-fa9d-44ea-9852-ae7b18bc1ab1@lunn.ch/ https://lore.kernel.org/rust-for-linux/c61a60ef-fa9d-44ea-98... The above thread is really strange that they picked such a niche thing in networking to contribute to, as sockets don't have many uses within the kernel itself other than NFS or dhcp or stuff like that. They should have aimed to add things to the QoS layer, qdisc, classifier, whatever, there's tens of those and you can easily add another. Start small. The problem really is that the people who want to see Rust in the linux kernel have next to no linux kernel background and have a poor understanding of how Linux works and how things are generally done. Also the people who contribute big things to the linux kernel usually have a clear business case behind them and a big company paying them to work on it full time. For example I could imagine Microsoft eventually contributing in this regard, say they want some more Hyper-V virtual hardware drivers in Linux and they decided to do that in Rust. They've been lately using Rust in the Windows kernel so it's not that unrealistic to think it may happen. A filesystem written in Rust would be cool... but it's probably going to have to be a new one rather than a rewrite, I can't imagine people going through the trouble of rewriting btrfs in Rust. And big names like Facebook could actually back that effort. I really love using Rust for middleware things, however right now I can't convince myself to use it on low level things like OSes or microcontrollers since it seems to be a lot of trouble with getting Rust to play nice with FreeRTOS for example, and there seems to be no production ready rtos written in Rust either.

Aurornis 3y ago
> Funny you ask, I was wondering the same thing last night so I went through the rust-for-linux mailing list archive. This thread is pretty telling: > https://lore.kernel.org/rust-for-linux/bddea099-4468-4f96-2e06-2b207b608485@usi.ch/ https://lore.kernel.org/rust-for-linux/bddea099-4468-4f96-2e... > https://lore.kernel.org/rust-for-linux/c61a60ef-fa9d-44ea-9852-ae7b18bc1ab1@lunn.ch/ https://lore.kernel.org/rust-for-linux/c61a60ef-fa9d-44ea-98... I don’t see how either post supports your points. The first is about OOT vs in-tree modules and the second isn’t about anything specific to Rust. You just picked a random post from someone learning about kernel development who happened to be using Rust. The people doing core Rust for Linux work (not random mailing list participants) are actually very qualified and very knowledgeable about Linux. I don’t think your characterization of them is fair at all. Grabbing random mailing list posts from non core maintainers and trying to extrapolate conclusions about an entire multi-year is not a good way to evaluate a project.
- patrick451 3y ago
  I don't have a dog in this fight, but " someone learning about kernel development who happened to be using Rust" sounds to me like anecdotal evidence for the assertion that most rust contributors don't know how kernel development works.
  - i_am_a_peasant 3y ago
    my point exactly..
- i_am_a_peasant 3y ago
  >The people doing core Rust for Linux work (not random mailing list >participants) are actually very qualified and very knowledgeable about > Linux. I don’t think your characterization of them is fair at all. Alright, they are very qualified and knowledgeable, what is a fair characterization of the work they're doing? It's been a year, let's see how much stuff they managed to merge, My terminal window has 135 rows: cd linux/ git log --oneline rust/ output <space> output <space> output <space> no output Oh wow, how many people was it again? git shortlog -s -n -e --all --no-merges rust/ | wc -l 29 Most of those guys have single digits number of commits and there are 7 guys with double digits number of commits so let's say there's about 7 people most active doing rust in linux. Do you know Rust yourself? Take a look at the bulk of the patches that got merged, could you write that if someone paid you? My guess is yes, because it looks pretty average to me. (No offense to you personally).
  - nevi-me 3y ago
    There's been 1500+ commits since 2020 on the 'main' Kernel fork that has Rust support [0]. Many of them through collaboration and backs and forths of review (look at the PRs on the fork). My understanding is that the `rust-next` branch represents what's ready for Linus to merge. So there's a whole lot that's not in there, which you're missing in your evaluation. Last year a Kernel dev from Western Digital wrote an NVME driver in Rust [1] (look at slides 15 & 16) which I would consider to be qualified and knowledgeable. I wouldn't measure the effort solely on what's been merged to mainline as there's been 6 merge windows from 6.1 to now. Many of those commits are laying the groundwork for the next few years. [0] https://github.com/torvalds/linux/compare/master...Rust-for-Linux:linux:rust https://github.com/torvalds/linux/compare/master...Rust-for-... [1] https://lpc.events/event/16/contributions/1180/attachments/1017/1961/deck.pdf https://lpc.events/event/16/contributions/1180/attachments/1...
zare_st 3y ago
The biggest point is in your second paragraph. "The problem really is that the people who want to see Rust in the linux kernel have next to no linux kernel background and have a poor understanding of how Linux works and how things are generally done." Is this a non topic then? Having drivers in Rust is one thing. Drivers were done in C++ before. But you use a subset because a language targeting kernel needs to use kernel facilities. You won't be able to use your standard library. Syntax needs to be resolved to what kernel provides, or dropped. That's why C++ in kernel never took off that seriously, when you restrict it, and when you already have to accommodate for kernel's "API mindset", what's left of language in between isn't that important.
- i_am_a_peasant 3y ago
  If C could get constexpr and templates (with concepts) I would be very happy. Everything else in C++ is just syntactic sugar to me. Very useful syntactic sugar, but just sugar. Alright placement new is quite nice too. Since there are so many ways to allocate memory in the linux kernel. As far as RAII goes, ehhhh I don't know. KASAN and kmemleak do a pretty ok job.

Aurornis 3y ago

> Funny you ask, I was wondering the same thing last night so I went through the rust-for-linux mailing list archive. This thread is pretty telling: > https://lore.kernel.org/rust-for-linux/bddea099-4468-4f96-2e06-2b207b608485@usi.ch/ https://lore.kernel.org/rust-for-linux/bddea099-4468-4f96-2e... > https://lore.kernel.org/rust-for-linux/c61a60ef-fa9d-44ea-9852-ae7b18bc1ab1@lunn.ch/ https://lore.kernel.org/rust-for-linux/c61a60ef-fa9d-44ea-98... I don’t see how either post supports your points. The first is about OOT vs in-tree modules and the second isn’t about anything specific to Rust. You just picked a random post from someone learning about kernel development who happened to be using Rust. The people doing core Rust for Linux work (not random mailing list participants) are actually very qualified and very knowledgeable about Linux. I don’t think your characterization of them is fair at all. Grabbing random mailing list posts from non core maintainers and trying to extrapolate conclusions about an entire multi-year is not a good way to evaluate a project.

patrick451 3y ago
I don't have a dog in this fight, but " someone learning about kernel development who happened to be using Rust" sounds to me like anecdotal evidence for the assertion that most rust contributors don't know how kernel development works.
- i_am_a_peasant 3y ago
  my point exactly..
i_am_a_peasant 3y ago
>The people doing core Rust for Linux work (not random mailing list >participants) are actually very qualified and very knowledgeable about > Linux. I don’t think your characterization of them is fair at all. Alright, they are very qualified and knowledgeable, what is a fair characterization of the work they're doing? It's been a year, let's see how much stuff they managed to merge, My terminal window has 135 rows: cd linux/ git log --oneline rust/ output <space> output <space> output <space> no output Oh wow, how many people was it again? git shortlog -s -n -e --all --no-merges rust/ | wc -l 29 Most of those guys have single digits number of commits and there are 7 guys with double digits number of commits so let's say there's about 7 people most active doing rust in linux. Do you know Rust yourself? Take a look at the bulk of the patches that got merged, could you write that if someone paid you? My guess is yes, because it looks pretty average to me. (No offense to you personally).
- nevi-me 3y ago
  There's been 1500+ commits since 2020 on the 'main' Kernel fork that has Rust support [0]. Many of them through collaboration and backs and forths of review (look at the PRs on the fork). My understanding is that the `rust-next` branch represents what's ready for Linus to merge. So there's a whole lot that's not in there, which you're missing in your evaluation. Last year a Kernel dev from Western Digital wrote an NVME driver in Rust [1] (look at slides 15 & 16) which I would consider to be qualified and knowledgeable. I wouldn't measure the effort solely on what's been merged to mainline as there's been 6 merge windows from 6.1 to now. Many of those commits are laying the groundwork for the next few years. [0] https://github.com/torvalds/linux/compare/master...Rust-for-Linux:linux:rust https://github.com/torvalds/linux/compare/master...Rust-for-... [1] https://lpc.events/event/16/contributions/1180/attachments/1017/1961/deck.pdf https://lpc.events/event/16/contributions/1180/attachments/1...

zare_st 3y ago

The biggest point is in your second paragraph. "The problem really is that the people who want to see Rust in the linux kernel have next to no linux kernel background and have a poor understanding of how Linux works and how things are generally done." Is this a non topic then? Having drivers in Rust is one thing. Drivers were done in C++ before. But you use a subset because a language targeting kernel needs to use kernel facilities. You won't be able to use your standard library. Syntax needs to be resolved to what kernel provides, or dropped. That's why C++ in kernel never took off that seriously, when you restrict it, and when you already have to accommodate for kernel's "API mindset", what's left of language in between isn't that important.

i_am_a_peasant 3y ago
If C could get constexpr and templates (with concepts) I would be very happy. Everything else in C++ is just syntactic sugar to me. Very useful syntactic sugar, but just sugar. Alright placement new is quite nice too. Since there are so many ways to allocate memory in the linux kernel. As far as RAII goes, ehhhh I don't know. KASAN and kmemleak do a pretty ok job.