It sounds so simple, I don't get it why the Rust people don't write their own operating system or bundle their human capital to such a project.
They have been trying for years now to integrate Rust in the Linux kernel they could have made some good progress on a rust only OS by now.
If only just a kernel that can run server like application without a gui shell.
There are many Rust OS mentioned in this thread. (Eg Redox)
But the success of an OS also depends on the availability of drivers, and it's hard to compete with existing proven OS such as Linux on that front.
This was never about the languages primarily though. The C programmers here would react the same way towards any other language, be it Zig or Swift, its not Rust specific. They just don't want to partake the additional headache they'll have to deal with to for making the Linux kernel more accessible to languages other than C.
Despite than, Rust devs kept on pushing it after all that was clearly stated, just to make things more and more annoying. Maintaining a software as huge and widely used as the Linux kernel is a huge responsibility that can't be relied on words like "leave it on our shoulders", especially when real time, immediate response is demanded. Development of something like the Linux kernel in Rust will be left unmaintained eventually, unless millions of dollahs are constantly invested into maintaining it because Rust is not as simple as C and the need to avoid accidental copying, memory leaks and almost all memory related issues will add more work because you can't escape "unsafe" when dealing with low level hadrware and C, making the usage of the Rust programming language for Linux kernel development utterly pointless.
I somewhat disagree on the "you can't escape unsafe" part. It's true for a C+Rust project, but the idea that you need an unsafe language for low level hardware access is plain wrong. That's a "C-ism". Something that might seem true in a universe where most low level work is done in C, but wouldn't be true in a universe where C doesn't exist at all.
its fine if you disagree and think that using "unsafe language" for low level hardware access is wrong but that doesn't change the fact that the more closer one operates to the hardware, the more bare-bone they need the tools to be or else they'll only get in the way of the job. Having to worry about something like a borrow checker or a reference counter just to manipulate a couple of bytes is not an efficient way to perform low level hardware programming.
Also, there is nothing wrong with any "unsafe language". Memory safety is a skill issue, not a language issue. All functional languages are safe and procedural languages are unsafe by nature. Its better to settle on a functional language and compromise on performance if memory safety is of utmost priority. The additional complexity and performance overhead of any supposedly safe procedural language is not worth it for doing low level stuff but it sure could be a fun choice when doing high level stuff.
There are softer ways to work with abrasive attitudes that can ultimately accomplish your goals. A key part of that is knowing which battles are worth fighting. Sometimes, it's better to let a suboptimal solution in to appease an ego.
I think Hector's change is the right one, but I also think with the dma maintainer being unwilling to budge the next move is to hack in a location with less resistance, potentially making more work and churn, but ultimately achieving the goal of rust in Linux.
Two people being abrasive to each other with code involved is a disaster.
Do you mean location as in different subsystem than dma, which is required for all modern devices.
Or just location as in stash the files outside the dma directory?
> Or just location as in stash the files outside the dma directory?
This one. The code in question, AFAIK, is a rust wrapper around the DMA subsystem. I think that does best belong in the DMA subsystem but with the maintainer unwilling to accept it the next place to put it is either in a new rust-dma subsystem/wrapper or to pull out the parts needed and integrate them directly in the drivers in question (certainly nasty and a lot of duplicate effort).
The goal for such code should ultimately be to cause as little friction as possible with the DMA maintainer.
If it comes up in the mailing list that "this is dumb and you shouldn't do this" that's when you loop in the DMA maintainer and request their suggestions on how to proceed with whoever challenges the change. Put them in the seat of making the decision of where the code should go.
If you don't want to use C perhaps you shouldn't contribute to a 33 year old project written in C?
It sounds so simple, I don't get it why the Rust people don't write their own operating system or bundle their human capital to such a project.
They have been trying for years now to integrate Rust in the Linux kernel they could have made some good progress on a rust only OS by now. If only just a kernel that can run server like application without a gui shell.
There are many Rust OS mentioned in this thread. (Eg Redox) But the success of an OS also depends on the availability of drivers, and it's hard to compete with existing proven OS such as Linux on that front.
2 replies →
No?
This was never about the languages primarily though. The C programmers here would react the same way towards any other language, be it Zig or Swift, its not Rust specific. They just don't want to partake the additional headache they'll have to deal with to for making the Linux kernel more accessible to languages other than C.
Despite than, Rust devs kept on pushing it after all that was clearly stated, just to make things more and more annoying. Maintaining a software as huge and widely used as the Linux kernel is a huge responsibility that can't be relied on words like "leave it on our shoulders", especially when real time, immediate response is demanded. Development of something like the Linux kernel in Rust will be left unmaintained eventually, unless millions of dollahs are constantly invested into maintaining it because Rust is not as simple as C and the need to avoid accidental copying, memory leaks and almost all memory related issues will add more work because you can't escape "unsafe" when dealing with low level hadrware and C, making the usage of the Rust programming language for Linux kernel development utterly pointless.
I somewhat disagree on the "you can't escape unsafe" part. It's true for a C+Rust project, but the idea that you need an unsafe language for low level hardware access is plain wrong. That's a "C-ism". Something that might seem true in a universe where most low level work is done in C, but wouldn't be true in a universe where C doesn't exist at all.
At work, we have an OS written entirely in Rust. You still need unsafe to make it work. Not much (3%) but it's nonzero.
The hardware is outside of Rust's safety guarantees. This is truly a fundamental issue.
its fine if you disagree and think that using "unsafe language" for low level hardware access is wrong but that doesn't change the fact that the more closer one operates to the hardware, the more bare-bone they need the tools to be or else they'll only get in the way of the job. Having to worry about something like a borrow checker or a reference counter just to manipulate a couple of bytes is not an efficient way to perform low level hardware programming.
Also, there is nothing wrong with any "unsafe language". Memory safety is a skill issue, not a language issue. All functional languages are safe and procedural languages are unsafe by nature. Its better to settle on a functional language and compromise on performance if memory safety is of utmost priority. The additional complexity and performance overhead of any supposedly safe procedural language is not worth it for doing low level stuff but it sure could be a fun choice when doing high level stuff.
As long as you can directly write registers, you can screw it.
Partially, but it takes two to tango.
There are softer ways to work with abrasive attitudes that can ultimately accomplish your goals. A key part of that is knowing which battles are worth fighting. Sometimes, it's better to let a suboptimal solution in to appease an ego.
I think Hector's change is the right one, but I also think with the dma maintainer being unwilling to budge the next move is to hack in a location with less resistance, potentially making more work and churn, but ultimately achieving the goal of rust in Linux.
Two people being abrasive to each other with code involved is a disaster.
Do you mean location as in different subsystem than dma, which is required for all modern devices. Or just location as in stash the files outside the dma directory?
> Or just location as in stash the files outside the dma directory?
This one. The code in question, AFAIK, is a rust wrapper around the DMA subsystem. I think that does best belong in the DMA subsystem but with the maintainer unwilling to accept it the next place to put it is either in a new rust-dma subsystem/wrapper or to pull out the parts needed and integrate them directly in the drivers in question (certainly nasty and a lot of duplicate effort).
The goal for such code should ultimately be to cause as little friction as possible with the DMA maintainer.
If it comes up in the mailing list that "this is dumb and you shouldn't do this" that's when you loop in the DMA maintainer and request their suggestions on how to proceed with whoever challenges the change. Put them in the seat of making the decision of where the code should go.