12 ms·

Linus Torvalds on where Rust will fit into Linux

212 points by CrankyBear 6y ago

KennyFromIT 6y ago
Linus: > I'm interested in the project, but I think it's driven by people who are very excited about Rust, and I want to see how it actually then ends up working in practice.
- brundolf 6y ago
  [deleted] (Deleted because I only meant to bring up the broader phenomenon of what makes a person feel "excited" or "unexcited" about a language; I was specifically trying (unsuccessfully) to avoid the hotbed topic that has arisen below)
  - steveklabnik 6y ago
    It would be a mistake to characterize this push as an "emotional concern." The main driver is security. The folks doing this work are advocates of memory safety first, and Rust second. It just so happens that in this particular context, Rust is the most appropriate choice. EDIT: it's all good! I didn't think your comments were bad.
    - brundolf 6y ago
      [deleted]
      - steveklabnik 6y ago
        I think it depends on what "re-write it in Rust" means. Some people say that it means folks specifically asking for a project to be re-written in Rust. Others seem to imply that any new code written in Rust counts. To illustrate the difference, ripgrep would be the latter, but not the former. If we're talking about the former, I think the actual instances of this are few and far between, and are complained about far more than actually occurs. At one point I was actually trying to get hard data on this, but there really were only a handful of times I could find this seriously occurring, and they were pretty easily dismissed. The folks who talk about it like a plague of some kind never seem to show their evidence, or link to one or two examples at best. If we're talking about the latter, it shouldn't be surprising that folks who like a language write software in that language. That's why languages exist. I don't know why some people really want to say that folks cannot write whatever software they want in whatever language they want.
        capableweb 6y ago
        > At one point I was actually trying to get hard data on this, but there really were only a handful of times I could find this seriously occurring This is probably depending on the environment. Corporate environments would move very slow, open source kind of fast and SMB/SME somewhere in the middle. All of them plagued by cargoculting, but especially average performing SMB/SME are the most guilty, and also where I've seen the most "Hey, we should probably rewrite this service in Rust because it'll be better for sure" since some years back.
        steveklabnik 6y ago
        Yes, this is a good point, for sure.
        capableweb 6y ago
        I actually stumbled upon[1] a data source for you! Seems there is some activity in the "Rewrite it in Rust" domain, and there is a collection of it being suggested in a lot of places: https://github.com/ansuz/RIIR https://github.com/ansuz/RIIR - [1] https://news.ycombinator.com/item?id=26561093 https://news.ycombinator.com/item?id=26561093
        steveklabnik 6y ago
        Right, but this is what I mean. If this is the best collection of stuff, well, it doesn't make a compelling argument that there is a huge scourge of this around the internet. Even if we assume these are all legit issues, there have been 66 total in the five years this repository has existed. That is a miniscule number. If we actually look at the issues, many of them are not instances of an outsider demanding a project being rewritten in Rust. Let's look at the most recent five issues, to pick a random sample: * https://github.com/ansuz/RIIR/issues/62 https://github.com/ansuz/RIIR/issues/62 This is showing a branch that the team themselves made. It is not an outside demand to re-write it in Rust. * https://github.com/ansuz/RIIR/issues/59 https://github.com/ansuz/RIIR/issues/59 This one does appear to be legit. Not a ton of drama here, a polite conversation that was closed without issue, even though its existence is generally a bit annoying, yes. * https://github.com/ansuz/RIIR/issues/58 https://github.com/ansuz/RIIR/issues/58 This again is someone who is doing this for their own project. * https://github.com/ansuz/RIIR/issues/57 https://github.com/ansuz/RIIR/issues/57 This is a transcription of a joke in a telegram chat. * https://github.com/ansuz/RIIR/issues/53 https://github.com/ansuz/RIIR/issues/53 This is a person who opened an issue on this project, but does not appear to have asked upstream about it. * https://github.com/ansuz/RIIR/issues/51 https://github.com/ansuz/RIIR/issues/51 This one is amusing, given the article, but again, isn't an upstream request. Let's look at recent closed issues: * https://github.com/ansuz/RIIR/issues/67 https://github.com/ansuz/RIIR/issues/67 This is a person who made this issue, then two minutes later, opened an issue being a jerk on the target repo. Yes, that is annoying for the person who had the issue opened, but is hardly an indication that these are real requests. This person is trolling. The next seven most recent closed issues are someone who has just opened issues with random technologies they thought they'd be funny. I was only gonna do five, like the opened issues, but it's clear this is a series, so have a bonus two. So already, we have like, let's round it up: two real issues here, out of fourteen. I am not convinced. (Your hacker news link seems like nonsense to me?)
    - busterarm 6y ago
      I think if security is a main concern of people working on Linux, there are both lower hanging fruit AND bigger fish to fry than getting code into Rust. Not that it isn't a worthy effort, but it's still an effort by people who are more excited about Rust than they are acting in the interest of security. Edit: It's almost a meme at this point that you can't even be remotely critical of Rust on this board without kneejerk mass downvoting.
      - steveklabnik 6y ago
        Do you know anything about the people whose motives you are questioning? What work they've done, and why? I think if you did, you may not say what you've said.
        busterarm 6y ago
        I'm well aware of whom I'm speaking to and the efforts made by others. I'm also well aware of lots of other security problems facing Linux that need love and the steps being taken by other operating systems where Linux lags behind. So while I'm not saying that there isn't a concern about security by the people involved, I am certainly saying why this as opposed to other things. I have my pet problems and areas where I prefer to work too.
      - pdimitar 6y ago
        > there are both lower hanging fruit AND bigger fish to fry than getting code into Rust. Do tell, I am very interested? > but it's still an effort by people who are more excited about Rust than they are acting in the interest of security Needlessly dismissive. What if the people got excited because of the increased security?
        busterarm 6y ago
        > Needlessly dismissive. What if the people got excited because of the increased security? If only people were so excited about making OpenSSL not a flaming hot bag of shit. Can't wait to find out what that patch on Thursday will be for.
  - capableweb 6y ago
    I think emotional reaction happens to a lot of things that we like, where we raise up their benefits and downplay their negatives. At least for the first few years, until we're in a different context or something else comes along that solves it even better. I also think that's why lisp people are so feverish about lisp as well: as you get more involved in the language with its charms, the more excitement you get and you want to see the language in more places/contexts
  - deleted 6y ago
    [deleted]
ilaksh 6y ago
People who are interested in OS security should fund Redox OS. https://www.patreon.com/redox_os https://www.patreon.com/redox_os The fact that he is only getting around $1,000 per month on Patreon points to deep, deep flaws in humanity. Especially when you compare it to other funding amounts for say Linux or popular smut on Patreon. A total lack of foresight and values.
- godman_8 6y ago
  Lol what? Deep flaws in humanity? All because some small time non-visible OS doesn't receive more funding? The only deep flaws I can see are within you generalizing an entire population because you don't get what you want.
  - edoceo 6y ago
    > generalizing an entire population because you don't get what you want. The true deep flaw of humanity.
- maxrev17 6y ago
  U wot m8?
- Bancakes 6y ago
  Yesterday it was openbsd, now its redux os. Any other flavour of the year you wanna share?
  - moistbar 6y ago
    2021 is the year of the Haiku desktop.
- happytoexplain 6y ago
  Redox OS getting much less than Linux or porn on Patreon points to deep, deep flaws in humanity and a total lack of foresight and values? I think there's probably a reasonable version of this opinion, but yours is intensely, unrealistically judgmental and righteous.
esgwpl 6y ago
>The kernel is different from userspace projects - more difficult in some respects (we use a lot of very odd header files that pushes the boundary of what can be called "C"), but easier in many other respects (mainly in the sense that the kernel is fairly self-contained, and then doesn't rely on other projects for the final binary). I'm interested in what Torvalds meant by these odd header files, does anyone know?
- tambourine_man 6y ago
  Probably some crazy macros that the kernel code uses. You can end up having an almost dialect of C with extensive use.
- cransoon 6y ago
  /* * This returns a constant expressionn while determining if an argument is * a constant expression, most importantly without evaluating the argument. * Glory to Martin Uecker <Martin.Uecker@med.uni-goettingen.de> */ #define __is_constexpr(x) \ (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
  - PixelOfDeath 6y ago
    The dark side of c is a pathway to many abilities, some considered to be unnatural
  - nmfisher 6y ago
    Jesus, can someone unravel that for me?
    - Koshkin 6y ago
      I can try... In short, this is about how a C compiler is supposed to deduce the type of the ternary operation. So, if x is a constant expression, the compiler figures that the second operand must be NULL (because it is allowed to perform the multiplication, by 0l), whose type then is whatever the third operand says (a pointer to int). The comparison succeeds. Otherwise the compiler does not perform the multiplication, takes the type of the second operand at its “face value”, i.e. as a pointer to void, and converts the type of the third operand to it - which, of course, makes the comparison false in this case.
gtsop 6y ago
I love the idea of more rust into linux because I think it will make the code more secure and easier to contribute/modify. I am scared of any potential problems an immature ecosystem (relative to C ofcourse, don't jump the gun) can cause to this life-depending tool called the linux kernel. I am glad linus is open to it but careful. Balanced approach Edit: I am also a proponent of careful re-writes of very old userspace utilities (eg: ping) accompanied by very rigorous tests to ensure there aren't any behavour changes
- enriquto 6y ago
  > I am also a proponent of careful re-writes of very old userspace utilities (eg: ping) accompanied by very rigorous tests to ensure there aren't any behavour changes That would be great, but a prerequisite for that is that the rust language is stable to ensure that there aren't any behaviour changes in the compiler itself.
  - nynx 6y ago
    Rust has been stable since 2015.
    - turminal 6y ago
      Always the same arguments, hilarious.
      - nynx 6y ago
        I'm not really sure how that's an argument. It's just a fact. Rust has been stable and backwards compatible since 2015.
        turminal 6y ago
        How many libraries written in 2015 rust have you actually tried using recently?
chomp 6y ago
Rust doesn't support the same amount of architectures C and Linux do, hopefully either Rust learns to support more architectures, or this stays confined to just driver code because I'd hate to see Linux disappear from some of the more esoteric architectures.
- dralley 6y ago
  > Another point is taking on drivers first for "any initial trials to drivers is simply the architecture side," said Torvalds. "Lots of drivers are only relevant on a couple of target architectures, so the whole issue with Rust code not being supported on some architectures is less of an issue."
- tambourine_man 6y ago
  Linus is very proud of Linux running on anything, from toasters to HPC, so I think it's safe to assume less common architectures aren't going away.
  - steveklabnik 6y ago
    Linux removes platform support from time to time, like any project. IA64 was a recent, notable example. That being said, it is true that Rust doesn't yet support all the platforms that are important to the kernel. That's one of the reasons this is starting with drivers, and is one of the reasons why some folks are pursuing a Rust frontend for gcc.
  - pm215 6y ago
    It depends entirely on whether there are still developers interested in maintaining support for those architectures. It seems pretty safe to assume that Torvalds isn't going to be in favour of "we drop anything without a rust backend tomorrow"; but on the other hand 8 archs were dropped in 2018 -- https://lwn.net/Articles/749292/ https://lwn.net/Articles/749292/ -- essentially for lack of any active interest in them. It's possible that eventually "set of archs with a rust backend" and "set of archs which people care about enough to keep alive in the kernel" converge to the same set. It's even possible that one day "does this even have a rust backend?" becomes a marker of "is this thing really of use to anybody" in the same way that in 2018 "does this thing have support in upstream gcc" was a marker for "maybe we can drop this". That would be years from now, if ever, though, IMHO.
dahfizz 6y ago
Can someone with more knowledge than me explain what benefit Rust presents to a low level codebase such as a kernel? I am a C programmer by trade who has played with Rust. It is a great language but there is very little you can do safely. In higher level projects you can mostly push the un-safety into the standard library. But when you have to do everything yourself, all of the "buggy" code has to be marked unsafe anyway. Allocating and accessing(!!) memory is unsafe. Interfacing with C or asm is unsafe. Your buffer/vector implementation is unsafe. Basically, all the common culprits for memory bugs in C would be the code marked unsafe if rewritten in rust. So what is the benefit?
- filmor 6y ago
  You'd write the allocator or low-level memory access logic once with unsafe code and afterwards all code using the functionality can be written as safe code. That limits the amount of code that can have data races.
- zanellato19 6y ago
  Accessing memory is not unsafe, wdym?
  - Asraelite 6y ago
    I guess dereferencing a raw pointer?
  - mcguire 6y ago
    Building memory management/allocation/malloc systems is.
  - megous 6y ago
    In a multi-core system, it may be, since you're not really accessing main memory directly, but you're going through several levels of all kinds of caches, some shared and some not (L1 (instruction, data), L2, L3, TLB, ...), and sometimes competing with devices that access the memory "directly" via DMA.
- steveklabnik 6y ago
xiphias2 6y ago
> From where Kroah-Hartman sits, "it will all come down to how well the interaction between the kernel core structures and lifetime rules that are written in C can be mapped into Rust structures and lifetime rules for drivers in Rust to be able to use them properly. That's going to take a lot of careful work by the developers wanting to hook this all up and I wish them the best of luck." It's really interesting that any C code already has to have a memory management ownership model, and the consistency of that model makes Rustification easy / hard.
scoutt 6y ago
I am all in for Rust in the kernel (as drivers) and I am really curious of how they will manage sharing memory across boundaries (user <--> kernel spaces). For example, an H264 encoder/decoder module in the kernel: let's say I have a Freescale/NXP i.MX6 platform with a HW H264 decoder, and I have to create kernel module to talk to it. Then use this module from an user space application to decode a video file. What I did (modified actually) in the past is a module that allocated a couple of (aligned) buffers in video memory and then passed them around between the HW decoder, kernel module and user space application. This is usually done to not force a deep copy of >100KB buffer for every decoded frame. This memory is shared between different parts of the implementation, meaning that the same buffer belongs to up to 3 parties at any given time. Also, the allocation is done once and lives for the entire application life, usually allocating like 3 buffer so when one buffer is being decoded I can still use already decoded buffers for writing them into a file. I know there is an alternative (hack?) using something called Pin (possibly clashing with, like, a GPIO Pin?) but I didn't get so deep already with Rust to really understand it. Ah! whatever driver/module they do, it should be accessible with C. So Rust must fill the gap between "Some C code in userland" <--> Rust <--> "More C code in the kernel", so I'm really interested to see how ownership works in this case. Userland C app says: "Hey Rust kernel module, take this struct and do something", the I go and change the contents of that struct from another thread in my userland application. Would this be possible?
- steveklabnik 6y ago
  Rust can handle these scenarios just fine. Specifically what you'd need to do depends on the exact semantics of the details here, but this big picture isn't a problem.
joshlk 6y ago
Has anyone tried c2rust on the Linux kernel? Does it provide any positive results?

212 points by CrankyBear 6y ago

Linus: > I'm interested in the project, but I think it's driven by people who are very excited about Rust, and I want to see how it actually then ends up working in practice.

brundolf 6y ago
[deleted] (Deleted because I only meant to bring up the broader phenomenon of what makes a person feel "excited" or "unexcited" about a language; I was specifically trying (unsuccessfully) to avoid the hotbed topic that has arisen below)
- steveklabnik 6y ago
  It would be a mistake to characterize this push as an "emotional concern." The main driver is security. The folks doing this work are advocates of memory safety first, and Rust second. It just so happens that in this particular context, Rust is the most appropriate choice. EDIT: it's all good! I didn't think your comments were bad.
  - brundolf 6y ago
    [deleted]
    - steveklabnik 6y ago
      I think it depends on what "re-write it in Rust" means. Some people say that it means folks specifically asking for a project to be re-written in Rust. Others seem to imply that any new code written in Rust counts. To illustrate the difference, ripgrep would be the latter, but not the former. If we're talking about the former, I think the actual instances of this are few and far between, and are complained about far more than actually occurs. At one point I was actually trying to get hard data on this, but there really were only a handful of times I could find this seriously occurring, and they were pretty easily dismissed. The folks who talk about it like a plague of some kind never seem to show their evidence, or link to one or two examples at best. If we're talking about the latter, it shouldn't be surprising that folks who like a language write software in that language. That's why languages exist. I don't know why some people really want to say that folks cannot write whatever software they want in whatever language they want.
      - capableweb 6y ago
        > At one point I was actually trying to get hard data on this, but there really were only a handful of times I could find this seriously occurring This is probably depending on the environment. Corporate environments would move very slow, open source kind of fast and SMB/SME somewhere in the middle. All of them plagued by cargoculting, but especially average performing SMB/SME are the most guilty, and also where I've seen the most "Hey, we should probably rewrite this service in Rust because it'll be better for sure" since some years back.
        steveklabnik 6y ago
        Yes, this is a good point, for sure.
        capableweb 6y ago
        I actually stumbled upon[1] a data source for you! Seems there is some activity in the "Rewrite it in Rust" domain, and there is a collection of it being suggested in a lot of places: https://github.com/ansuz/RIIR https://github.com/ansuz/RIIR - [1] https://news.ycombinator.com/item?id=26561093 https://news.ycombinator.com/item?id=26561093
        steveklabnik 6y ago
        Right, but this is what I mean. If this is the best collection of stuff, well, it doesn't make a compelling argument that there is a huge scourge of this around the internet. Even if we assume these are all legit issues, there have been 66 total in the five years this repository has existed. That is a miniscule number. If we actually look at the issues, many of them are not instances of an outsider demanding a project being rewritten in Rust. Let's look at the most recent five issues, to pick a random sample: * https://github.com/ansuz/RIIR/issues/62 https://github.com/ansuz/RIIR/issues/62 This is showing a branch that the team themselves made. It is not an outside demand to re-write it in Rust. * https://github.com/ansuz/RIIR/issues/59 https://github.com/ansuz/RIIR/issues/59 This one does appear to be legit. Not a ton of drama here, a polite conversation that was closed without issue, even though its existence is generally a bit annoying, yes. * https://github.com/ansuz/RIIR/issues/58 https://github.com/ansuz/RIIR/issues/58 This again is someone who is doing this for their own project. * https://github.com/ansuz/RIIR/issues/57 https://github.com/ansuz/RIIR/issues/57 This is a transcription of a joke in a telegram chat. * https://github.com/ansuz/RIIR/issues/53 https://github.com/ansuz/RIIR/issues/53 This is a person who opened an issue on this project, but does not appear to have asked upstream about it. * https://github.com/ansuz/RIIR/issues/51 https://github.com/ansuz/RIIR/issues/51 This one is amusing, given the article, but again, isn't an upstream request. Let's look at recent closed issues: * https://github.com/ansuz/RIIR/issues/67 https://github.com/ansuz/RIIR/issues/67 This is a person who made this issue, then two minutes later, opened an issue being a jerk on the target repo. Yes, that is annoying for the person who had the issue opened, but is hardly an indication that these are real requests. This person is trolling. The next seven most recent closed issues are someone who has just opened issues with random technologies they thought they'd be funny. I was only gonna do five, like the opened issues, but it's clear this is a series, so have a bonus two. So already, we have like, let's round it up: two real issues here, out of fourteen. I am not convinced. (Your hacker news link seems like nonsense to me?)
  - busterarm 6y ago
    I think if security is a main concern of people working on Linux, there are both lower hanging fruit AND bigger fish to fry than getting code into Rust. Not that it isn't a worthy effort, but it's still an effort by people who are more excited about Rust than they are acting in the interest of security. Edit: It's almost a meme at this point that you can't even be remotely critical of Rust on this board without kneejerk mass downvoting.
    - steveklabnik 6y ago
      Do you know anything about the people whose motives you are questioning? What work they've done, and why? I think if you did, you may not say what you've said.
      - busterarm 6y ago
        I'm well aware of whom I'm speaking to and the efforts made by others. I'm also well aware of lots of other security problems facing Linux that need love and the steps being taken by other operating systems where Linux lags behind. So while I'm not saying that there isn't a concern about security by the people involved, I am certainly saying why this as opposed to other things. I have my pet problems and areas where I prefer to work too.
    - pdimitar 6y ago
      > there are both lower hanging fruit AND bigger fish to fry than getting code into Rust. Do tell, I am very interested? > but it's still an effort by people who are more excited about Rust than they are acting in the interest of security Needlessly dismissive. What if the people got excited because of the increased security?
      - busterarm 6y ago
        > Needlessly dismissive. What if the people got excited because of the increased security? If only people were so excited about making OpenSSL not a flaming hot bag of shit. Can't wait to find out what that patch on Thursday will be for.
- capableweb 6y ago
  I think emotional reaction happens to a lot of things that we like, where we raise up their benefits and downplay their negatives. At least for the first few years, until we're in a different context or something else comes along that solves it even better. I also think that's why lisp people are so feverish about lisp as well: as you get more involved in the language with its charms, the more excitement you get and you want to see the language in more places/contexts
- deleted 6y ago
  [deleted]

ilaksh 6y ago

People who are interested in OS security should fund Redox OS. https://www.patreon.com/redox_os https://www.patreon.com/redox_os The fact that he is only getting around $1,000 per month on Patreon points to deep, deep flaws in humanity. Especially when you compare it to other funding amounts for say Linux or popular smut on Patreon. A total lack of foresight and values.

godman_8 6y ago
Lol what? Deep flaws in humanity? All because some small time non-visible OS doesn't receive more funding? The only deep flaws I can see are within you generalizing an entire population because you don't get what you want.
- edoceo 6y ago
  > generalizing an entire population because you don't get what you want. The true deep flaw of humanity.
maxrev17 6y ago
U wot m8?
Bancakes 6y ago
Yesterday it was openbsd, now its redux os. Any other flavour of the year you wanna share?
- moistbar 6y ago
  2021 is the year of the Haiku desktop.
happytoexplain 6y ago
Redox OS getting much less than Linux or porn on Patreon points to deep, deep flaws in humanity and a total lack of foresight and values? I think there's probably a reasonable version of this opinion, but yours is intensely, unrealistically judgmental and righteous.

esgwpl 6y ago

>The kernel is different from userspace projects - more difficult in some respects (we use a lot of very odd header files that pushes the boundary of what can be called "C"), but easier in many other respects (mainly in the sense that the kernel is fairly self-contained, and then doesn't rely on other projects for the final binary). I'm interested in what Torvalds meant by these odd header files, does anyone know?

tambourine_man 6y ago
Probably some crazy macros that the kernel code uses. You can end up having an almost dialect of C with extensive use.
cransoon 6y ago
/* * This returns a constant expressionn while determining if an argument is * a constant expression, most importantly without evaluating the argument. * Glory to Martin Uecker <Martin.Uecker@med.uni-goettingen.de> */ #define __is_constexpr(x) \ (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
- PixelOfDeath 6y ago
  The dark side of c is a pathway to many abilities, some considered to be unnatural
- nmfisher 6y ago
  Jesus, can someone unravel that for me?
  - Koshkin 6y ago
    I can try... In short, this is about how a C compiler is supposed to deduce the type of the ternary operation. So, if x is a constant expression, the compiler figures that the second operand must be NULL (because it is allowed to perform the multiplication, by 0l), whose type then is whatever the third operand says (a pointer to int). The comparison succeeds. Otherwise the compiler does not perform the multiplication, takes the type of the second operand at its “face value”, i.e. as a pointer to void, and converts the type of the third operand to it - which, of course, makes the comparison false in this case.

gtsop 6y ago

I love the idea of more rust into linux because I think it will make the code more secure and easier to contribute/modify. I am scared of any potential problems an immature ecosystem (relative to C ofcourse, don't jump the gun) can cause to this life-depending tool called the linux kernel. I am glad linus is open to it but careful. Balanced approach Edit: I am also a proponent of careful re-writes of very old userspace utilities (eg: ping) accompanied by very rigorous tests to ensure there aren't any behavour changes

enriquto 6y ago
> I am also a proponent of careful re-writes of very old userspace utilities (eg: ping) accompanied by very rigorous tests to ensure there aren't any behavour changes That would be great, but a prerequisite for that is that the rust language is stable to ensure that there aren't any behaviour changes in the compiler itself.
- nynx 6y ago
  Rust has been stable since 2015.
  - turminal 6y ago
    Always the same arguments, hilarious.
    - nynx 6y ago
      I'm not really sure how that's an argument. It's just a fact. Rust has been stable and backwards compatible since 2015.
      - turminal 6y ago
        How many libraries written in 2015 rust have you actually tried using recently?

chomp 6y ago

Rust doesn't support the same amount of architectures C and Linux do, hopefully either Rust learns to support more architectures, or this stays confined to just driver code because I'd hate to see Linux disappear from some of the more esoteric architectures.

dralley 6y ago
> Another point is taking on drivers first for "any initial trials to drivers is simply the architecture side," said Torvalds. "Lots of drivers are only relevant on a couple of target architectures, so the whole issue with Rust code not being supported on some architectures is less of an issue."
tambourine_man 6y ago
Linus is very proud of Linux running on anything, from toasters to HPC, so I think it's safe to assume less common architectures aren't going away.
- steveklabnik 6y ago
  Linux removes platform support from time to time, like any project. IA64 was a recent, notable example. That being said, it is true that Rust doesn't yet support all the platforms that are important to the kernel. That's one of the reasons this is starting with drivers, and is one of the reasons why some folks are pursuing a Rust frontend for gcc.
- pm215 6y ago
  It depends entirely on whether there are still developers interested in maintaining support for those architectures. It seems pretty safe to assume that Torvalds isn't going to be in favour of "we drop anything without a rust backend tomorrow"; but on the other hand 8 archs were dropped in 2018 -- https://lwn.net/Articles/749292/ https://lwn.net/Articles/749292/ -- essentially for lack of any active interest in them. It's possible that eventually "set of archs with a rust backend" and "set of archs which people care about enough to keep alive in the kernel" converge to the same set. It's even possible that one day "does this even have a rust backend?" becomes a marker of "is this thing really of use to anybody" in the same way that in 2018 "does this thing have support in upstream gcc" was a marker for "maybe we can drop this". That would be years from now, if ever, though, IMHO.

dahfizz 6y ago

Can someone with more knowledge than me explain what benefit Rust presents to a low level codebase such as a kernel? I am a C programmer by trade who has played with Rust. It is a great language but there is very little you can do safely. In higher level projects you can mostly push the un-safety into the standard library. But when you have to do everything yourself, all of the "buggy" code has to be marked unsafe anyway. Allocating and accessing(!!) memory is unsafe. Interfacing with C or asm is unsafe. Your buffer/vector implementation is unsafe. Basically, all the common culprits for memory bugs in C would be the code marked unsafe if rewritten in rust. So what is the benefit?

filmor 6y ago
You'd write the allocator or low-level memory access logic once with unsafe code and afterwards all code using the functionality can be written as safe code. That limits the amount of code that can have data races.
zanellato19 6y ago
Accessing memory is not unsafe, wdym?
- Asraelite 6y ago
  I guess dereferencing a raw pointer?
- mcguire 6y ago
  Building memory management/allocation/malloc systems is.
- megous 6y ago
  In a multi-core system, it may be, since you're not really accessing main memory directly, but you're going through several levels of all kinds of caches, some shared and some not (L1 (instruction, data), L2, L3, TLB, ...), and sometimes competing with devices that access the memory "directly" via DMA.
steveklabnik 6y ago

xiphias2 6y ago

> From where Kroah-Hartman sits, "it will all come down to how well the interaction between the kernel core structures and lifetime rules that are written in C can be mapped into Rust structures and lifetime rules for drivers in Rust to be able to use them properly. That's going to take a lot of careful work by the developers wanting to hook this all up and I wish them the best of luck." It's really interesting that any C code already has to have a memory management ownership model, and the consistency of that model makes Rustification easy / hard.

scoutt 6y ago

I am all in for Rust in the kernel (as drivers) and I am really curious of how they will manage sharing memory across boundaries (user <--> kernel spaces). For example, an H264 encoder/decoder module in the kernel: let's say I have a Freescale/NXP i.MX6 platform with a HW H264 decoder, and I have to create kernel module to talk to it. Then use this module from an user space application to decode a video file. What I did (modified actually) in the past is a module that allocated a couple of (aligned) buffers in video memory and then passed them around between the HW decoder, kernel module and user space application. This is usually done to not force a deep copy of >100KB buffer for every decoded frame. This memory is shared between different parts of the implementation, meaning that the same buffer belongs to up to 3 parties at any given time. Also, the allocation is done once and lives for the entire application life, usually allocating like 3 buffer so when one buffer is being decoded I can still use already decoded buffers for writing them into a file. I know there is an alternative (hack?) using something called Pin (possibly clashing with, like, a GPIO Pin?) but I didn't get so deep already with Rust to really understand it. Ah! whatever driver/module they do, it should be accessible with C. So Rust must fill the gap between "Some C code in userland" <--> Rust <--> "More C code in the kernel", so I'm really interested to see how ownership works in this case. Userland C app says: "Hey Rust kernel module, take this struct and do something", the I go and change the contents of that struct from another thread in my userland application. Would this be possible?

steveklabnik 6y ago
Rust can handle these scenarios just fine. Specifically what you'd need to do depends on the exact semantics of the details here, but this big picture isn't a problem.

joshlk 6y ago

Has anyone tried c2rust on the Linux kernel? Does it provide any positive results?