This maintains cargo's dependency resolution/update checking/etc, but also allows for all dependency code to be kept alongside the kernel code and audited accordingly.
As said in the article, "the world is changing". However, the way the world is changing is that more and more people are aware of supply-chain attacks. While I acknowledge that Cargo isn't npm, it is still the case that of all the software that can not afford to just sorta grab things from the internet, the Linux kernel is arguably #1, straight up. There is no chance that the kernel developers are ever going to accept "well, I wanted some async stuff so I grabbed a v0.5.23 of a package that I found appealing". Even if they pull some stuff in, it will be through a review process and it won't be through cargo in general.
The argument against cargo or any equivalent being used in the kernel is stronger today than it was 10 years ago, and the first derivative is also positive. Probably the second one too, honestly. This isn't about kernel developers being old fogey sticks in the mud, this is about the kernel being such a high-assurance environment, the biggest, fattest target in the world, that things that make sense for most software packages don't make sense for it. And it has nothing to do with cargo specifically or Rust. It's just that the entire workflow afforded by cargo, or npm, or go modules, or the half-dozen Python package managers, or anything else resembling those things is simply not appropriate for the Linux kernel. The only way to make such a thing work would be to pin the versions so hard that you're effectively only using them as a downloader, not a package manager, and you might as well just have vendored code in the kernel repo anyhow.
> The only way to make such a thing work would be to pin the versions so hard that you're effectively only using them as a downloader, not a package manager, and you might as well just have vendored code in the kernel repo anyhow.
This is the exact thing the person you replied to said should be done. `cargo vendor` fetches the sources for the package @ the version stated and embeds them in the repo. After that all deps would be sourced from the repository itself.
Nothing in the review process would have to change beyond adding a dependencies directory to the repo with a dedicated set of CODEOWNERS to handle reviewing patches with new dependencies.
What happens if a dependency adds a system call something? Libraries intended for kernel-friendly use cases really need that scope to be an intentional goal.
As for syscalls, Rust has a whole ecosystem of no_std crates for kernel and microcontroller development that already assume the lack of an OS. We use (and contribute to) such crates extensively in our product (which is already developed jointly with the Linux Foundation, though we're not working on the Linux kernel (well we are a little bit, but all of that work is still in C :P )) and can vouch for their quality.
They are not “too lazy”. It’s not economically viable for them to do so for various reasons.
[1] https://www.schneier.com/essays/archives/2003/11/liability_c...
AFAIK, in Haskell, any function that returns IO must indicate it in the type signature.
If you could find a way to take that idea, expand upon it with much more fine-grained types, then you could build an ecosystem where any system call, external network call, use of env variables, etc is baked into the type signature of every function and package. If you could do that, you could build pretty trivial checks to ensure that a given package doesn't perform any kind of system call.
So sort of like the types of permissions we assign to apps on Android, but represented (and enforced) directly in the type system.
It would be difficult to make something like this ergonomic but could be pretty cool.
Anything similar in rust would have to be enforced through code auditing tools, either forking the compiler, using some of its code as a basis or starting from scratch.
I should have prefaced my comment with a note that this was way more speculative :)
Now, Copilot is probably more specialized than even kernel dev, but AFAICT there's not really any hard barrier there. "Just" a question of effort.
Everybody knows that there are escape hatches because they are actually sometimes absolutely required for asymptotics or just plainly because it may be too hard to "prove" that your code is safe to the compiler.
That isn't a gotcha -- you know exactly what code you need to audit extra carefully.
[0] That one's actually in ByteString to technically not standard Haskell, but I just like the name.
I wonder if this is a real and considered need, or a knee-jerk response to try to put everything in rust and directly in ring 0 just for the sake of it. I see no reason to try to break down the "divide between kernel and user space" in this way, and I wonder what's actually driving it here.
I wish this article went a little deeper into _what specifically_ these Rust users are trying to make modules _for_.