5 ms·

I can't think of anything that could more effectively discredit the effort to use rust in the Linux kernel than suggesting using crates.io/cargo -- I had to che

by nullc 5y ago

I can't think of anything that could more effectively discredit the effort to use rust in the Linux kernel than suggesting using crates.io/cargo -- I had to check the dates just to make sure this wasn't a delayed April first post. But I guess some people just really want the unicode ukrainian flags being appended to every email they send or something and are too lazy to implement it themselves. :P

ratorx 5y ago
Why does a single bad idea discredit an entire language being included? If someone suggested including a C dependency manager in the kernel, does that mean that the use of the entire C language in kernel should be discredited? It is fair to say that the developer suggesting it (especially considering some of the proposed crates they want) has some massive misconceptions about the constraints of current Linux kernel development though.
- sanderjd 5y ago
  Yeah, my stance on this is that it probably makes sense to pull some libraries into the tree that would be useful in kernel development and which have comprehensible dependency trees such that everything could be reviewed and audited. But then I saw the quoted list and thought "oh this doesn't seem like a very serious proposal".
xorvoid 5y ago
Same thought. Seriously, what a great way to trigger some senior kernel dev to come down and straight veto rust with some rant about how it’s “worse C++” Rust is very slowly winning (but it’s a really hard space and this is impressive). But some people have to come and try snatching defeat from the jaws of victory. (sigh)
OskarS 5y ago
Indeed. The comment cited in the article is pretty stunning: > Other crates that I'd like: anyhow, bincode, byteorder, log, once_cell, pin-project, rand, serde, slab, static_assertions, uuid plus some more esoteric ones. This makes Rust devs look infantile, with no real understanding of what it means to develop for the kernel. Or what it takes to develop security and performance critical software of any kind, frankly.
- zozbot234 5y ago
  Most Rust "crates" are compile-time convenience features that add comparatively little binary code to the final build. The requests are plenty reasonable from that POV, although "vendoring" the deps might still introduce some complexity.
- varajelle 5y ago
  Can you please elaborate? These crates are no_std and provide functionality which seems useful regardless of on the kernel or not. I don't understand why it looks bad from a performance or security point of view. These crate are well established and developed by competant devs that also care about security and performance.
  - duckerude 5y ago
    anyhow is for careless error propagation, where you know you won't do elaborate handling and just bubble it up to the user. It's suitable for (some) applications, but not for libraries, and a kernel falls on the "library" side of that divide. Errors should be handled by the kernel itself or reported carefully to userspace. anyhow is not built for that. (It also puts its errors on the heap—what do you do if memory allocation fails when reporting an error?) Linux has its own UUID infrastructure, so it seems weird to pull in a whole parallel implementation. At the very least you'd want to disable all the generation code, and it's unclear to me if the uuid crate supports that. rand is large. Does Linux need all the probability distributions it supports? (ripgrepping for "Bernoulli" only turns up the name of a floppy disk system, so probably not.) Doesn't it already have an implementation for the ones it does need?
    - estebank 5y ago
      > It's suitable for (some) applications, but not for libraries, and a kernel falls on the "library" side of that divide. I would disagree with that assertion: the kernel is a service that end user applications interact with through an API. Using anyhow in a Rust library that Rust applications use is a very bad idea. Using anyhow in the kernel might be a bad idea, but not for that stated reason. > Linux has its own UUID infrastructure, so it seems weird to pull in a whole parallel implementation. At the very least you'd want to disable all the generation code, and it's unclear to me if the uuid crate supports that. The uuid crate can be modified to support the kernel infrastructure as its backend. This would allow the same API to be available within the kernel and in the rest of the ecosystem. That's beneficial to everyone involved.

by nullc 5y ago

ratorx 5y ago

Why does a single bad idea discredit an entire language being included? If someone suggested including a C dependency manager in the kernel, does that mean that the use of the entire C language in kernel should be discredited? It is fair to say that the developer suggesting it (especially considering some of the proposed crates they want) has some massive misconceptions about the constraints of current Linux kernel development though.

sanderjd 5y ago
Yeah, my stance on this is that it probably makes sense to pull some libraries into the tree that would be useful in kernel development and which have comprehensible dependency trees such that everything could be reviewed and audited. But then I saw the quoted list and thought "oh this doesn't seem like a very serious proposal".

xorvoid 5y ago

Same thought. Seriously, what a great way to trigger some senior kernel dev to come down and straight veto rust with some rant about how it’s “worse C++” Rust is very slowly winning (but it’s a really hard space and this is impressive). But some people have to come and try snatching defeat from the jaws of victory. (sigh)

OskarS 5y ago

Indeed. The comment cited in the article is pretty stunning: > Other crates that I'd like: anyhow, bincode, byteorder, log, once_cell, pin-project, rand, serde, slab, static_assertions, uuid plus some more esoteric ones. This makes Rust devs look infantile, with no real understanding of what it means to develop for the kernel. Or what it takes to develop security and performance critical software of any kind, frankly.

zozbot234 5y ago
Most Rust "crates" are compile-time convenience features that add comparatively little binary code to the final build. The requests are plenty reasonable from that POV, although "vendoring" the deps might still introduce some complexity.
varajelle 5y ago
Can you please elaborate? These crates are no_std and provide functionality which seems useful regardless of on the kernel or not. I don't understand why it looks bad from a performance or security point of view. These crate are well established and developed by competant devs that also care about security and performance.
- duckerude 5y ago
  anyhow is for careless error propagation, where you know you won't do elaborate handling and just bubble it up to the user. It's suitable for (some) applications, but not for libraries, and a kernel falls on the "library" side of that divide. Errors should be handled by the kernel itself or reported carefully to userspace. anyhow is not built for that. (It also puts its errors on the heap—what do you do if memory allocation fails when reporting an error?) Linux has its own UUID infrastructure, so it seems weird to pull in a whole parallel implementation. At the very least you'd want to disable all the generation code, and it's unclear to me if the uuid crate supports that. rand is large. Does Linux need all the probability distributions it supports? (ripgrepping for "Bernoulli" only turns up the name of a floppy disk system, so probably not.) Doesn't it already have an implementation for the ones it does need?
  - estebank 5y ago
    > It's suitable for (some) applications, but not for libraries, and a kernel falls on the "library" side of that divide. I would disagree with that assertion: the kernel is a service that end user applications interact with through an API. Using anyhow in a Rust library that Rust applications use is a very bad idea. Using anyhow in the kernel might be a bad idea, but not for that stated reason. > Linux has its own UUID infrastructure, so it seems weird to pull in a whole parallel implementation. At the very least you'd want to disable all the generation code, and it's unclear to me if the uuid crate supports that. The uuid crate can be modified to support the kernel infrastructure as its backend. This would allow the same API to be available within the kernel and in the rest of the ecosystem. That's beneficial to everyone involved.