But the one time I looked at a rust git repo I couldn’t even find where the code to do a thing was.
IMO that tells more about how the project was organized and names things than the language used.
So I think probably, the best way IS to go the way linus did. Just go ahead and write a very basic working kernel in rust. If the project is popular it will gain momentum.
As the other commenter pointed out, there’s Redox. The issue is that this completly disregards an incremental approach: you have to rewrite everything before it comes usable, you can’t do it piece by piece. Currently the approach of Rust for Linux is not even to rewrite things, but to allow writing new drivers in Rust.
Trying to slowly adapt parts of the kernel to rust and then complain when long term C developers don’t want to learn a new language in order to help isn’t going to make many friends on that team.
Have you seen the conference video? That’s not just refusal to learn a new language, it’s open hostility. And it’s not the only instance, for example Asahi Lina also reported unreasonable behaviour by some maintainers just because she wrote Rust code, even when Rust was not involved.
I think the point of redox is more than just rewriting Linux in Rust. Architecturally they are very different. Redox uses the more modern microkernel approach, whereas Linux is a modular monolith. There are advantages and disadvantages to both designs. They are actually polar opposites in fact. The compromise is something called a hybrid kernel which is used by Windows NT.
This is true, but the differences go even further than that. Redox is intentionally non-posix-compliant. This means that userspace programs written for posix operating systems may or may not need patching to even compile.
Part of the philosophy of Redox is to follow the beaten path mostly, but not be afraid of exploring better ideas when appropriate.
I’m not sure. I remember seeing an example in the docs, but I can’t find it now. Actually the docs in general are a lot less opinionated than I remember them.
One thing that I did find is that the ion shell document mentions that it isn’t a posix compliant shell because they would have had to leave out a bunch of features.
IMO that tells more about how the project was organized and names things than the language used.
As the other commenter pointed out, there’s Redox. The issue is that this completly disregards an incremental approach: you have to rewrite everything before it comes usable, you can’t do it piece by piece. Currently the approach of Rust for Linux is not even to rewrite things, but to allow writing new drivers in Rust.
Have you seen the conference video? That’s not just refusal to learn a new language, it’s open hostility. And it’s not the only instance, for example Asahi Lina also reported unreasonable behaviour by some maintainers just because she wrote Rust code, even when Rust was not involved.
I think the point of redox is more than just rewriting Linux in Rust. Architecturally they are very different. Redox uses the more modern microkernel approach, whereas Linux is a modular monolith. There are advantages and disadvantages to both designs. They are actually polar opposites in fact. The compromise is something called a hybrid kernel which is used by Windows NT.
This is true, but the differences go even further than that. Redox is intentionally non-posix-compliant. This means that userspace programs written for posix operating systems may or may not need patching to even compile.
Part of the philosophy of Redox is to follow the beaten path mostly, but not be afraid of exploring better ideas when appropriate.
What part of posix is redox trying to get away from?
I’m not sure. I remember seeing an example in the docs, but I can’t find it now. Actually the docs in general are a lot less opinionated than I remember them.
One thing that I did find is that the ion shell document mentions that it isn’t a posix compliant shell because they would have had to leave out a bunch of features.