[deleted]
Maestro: A Linux-compatible kernel in Rust
141–150 of 380 posts
Re: Maestro: A Linux-compatible kernel in Rust
#142Earlier quoted context omitted.
If you find this amazing, perhaps you should take a look at seL4, which has formal proofs of correctness, going all the way down to the generated assembly code still satisfying the requirements. It also has a much better overall architecture, the best currently available: A third generation microkernel multiserver system. It provides a protected (with proof of isolation) RTOS with hard realtime, proof of worst case t…
I wish L4 had taken off for general purpose computing. That and Plan9 are things I'd really like to try out but I don't have space to fit operating systems in amongst the other projects. They both strike me as having the Unix nature, either "everything is messages in userspace processes" or "everything is a file."
I don't think I've ever seen an argument for why "everything is a file" is a desirable thing. It seems like a kitchen where "everything is a bowl". Fine when you want to eat cereal, mix a cake, do some handwashing up, store some fruit; tolerable when you want to bake a cake in the oven. Intolerable when you've got a carrot in a bowl-shaped chopping board and you've got to peel and cut it using a bowl.
Why in principle should everything we do on computers behave and beshaped like a file?
Re: Maestro: A Linux-compatible kernel in Rust
#143Earlier quoted context omitted.
If you spend time reading the article, you can agree or disagree with his choices, but he provides several reasons for why he chose to rewrite in Rust over after the initial project was written in C: "At that moment, I decided to switch to Rust (my first project in this language), which represented several advantages: - Restart the project from the beginning, using lessons learned from previous mistakes - Be a bit mo…
That's pure Rust evangelism. As devs we are responsible for what we send out into the world. A schism in the Linux kernel would be bad.
Why? There are multiple kernel versons with different support. Android had and might still have their own kernel version, and I didn't notice anything bad. It's just another Unix implication.
Re: Maestro: A Linux-compatible kernel in Rust
#144Sounds like a fun project. Curious though: most of the drawbacks to using C and difficulties with developing an OS are around debugging. I assume that the switch to Rust eliminated a certain class of memory error but is debugging still a pain? Or is there less of it than before the switch making debugging more tolerable?
A lot of memory and concurrency issues have been eliminated.
It is still a pain to debug, but a lot less than it was before though.
As an example, there is not a lot of chances you forget to use a mutex since the compiler would remind it to you by an error.
This is not a silver bullet though, things such as deadlocks are still present. Especially with interruptions.
To give an example, if you decide to lock a mutex, then an interruption happens, the code that locks the mutex will stop running until the interruption is over. If the interruption itself tries to lock the same mutex, then you have a deadlock, and the typing system cannot help you with this kind of problem.
The solution is to disable interruptions handling while the mutex is locked, but the compiler cannot enforce it.
Re: Maestro: A Linux-compatible kernel in Rust
#145Earlier quoted context omitted.
This is severely wrong: you cannot compare hand written and properly commented assembly with compiler generated one.
Compare in what way? Handwritten and commented assembly will be much easier for a human to maintain. However modern optimizers are much more likely to apply the correct micro optimization tricks to get the best performance - and they can output different assembly for different variations of the same instruction set with ease, something that would make the hand written assembly much more complex.
"Handwritten and commented assembly will be much easier for a human to maintain"
It seems some people here have issue acknowledging that.
But where you are wrong: for modern micro-archs, everything mostly happens at runtime. Specific micro-archs optimizations are not done anymore, the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in the end). Usually, you only just care of basic static optimizations, like cache line, fetch code window, alignment, which are more writing "correct" assembly code than anything else.
And even with that, in the worst case scenarios, one could write some specific micro-arch code paths, not an issue while thinking long term of many software components life cycle, which would be "installed"/"branched to" at runtime. At least that knowledge would not be hidden deep in the absurd complexity of an optimizing compiler...
Re: Maestro: A Linux-compatible kernel in Rust
#146I think this had already been attempted by the now-discontinued project [Kerla]( https://github.com/nuta/kerla ).
I didn't know this project. I will check it out!
Re: Maestro: A Linux-compatible kernel in Rust
#147Earlier quoted context omitted.
If you spend time reading the article, you can agree or disagree with his choices, but he provides several reasons for why he chose to rewrite in Rust over after the initial project was written in C: "At that moment, I decided to switch to Rust (my first project in this language), which represented several advantages: - Restart the project from the beginning, using lessons learned from previous mistakes - Be a bit mo…
That's pure Rust evangelism. As devs we are responsible for what we send out into the world. A schism in the Linux kernel would be bad.
Linux started out as a hobby project that widened the schism in the Unix world. Yet things turned out fine
Re: Maestro: A Linux-compatible kernel in Rust
#148A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge. Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary…
I didn't know Firecracker existed, that's really awesome. Looks to be in Rust as well. I'll have to look at how this differs from the approach that Docker uses, my understanding is that Docker uses cgroups and some other built-in Linux features.
Re: Maestro: A Linux-compatible kernel in Rust
#149Earlier quoted context omitted.
You are right in a legacy context where the mess of ISAs required an abstraction of the assembly language. But where you are wrong is, moving forward in a world with a modern worldwide standard ISA (RISC-V) is actually writing a kernel in assembly (without abusing any preprocessing).
RISC-v assembly is not substantially easier to write than any other assembly. RISC assemblies in general (aka MIPS, Arm, RV64 etc) require more instructions to accomplish the same tasks. I would argue they are designed with compilers in mind more than human authors. Older assemblies expected the programmer to be programming in assembly directly, which is why they allow you to express your intent more directly than RI…
RISC-V is a modern load-store ISA. Is is very clean, much more than the mess of x86_64 for instance. It is actually better to write RISC-V than x86_64, even if the later is CISC.
Re: Maestro: A Linux-compatible kernel in Rust
#150This is obviously impressive. Did you think from the beginning monolithic/module-based like linux was the way to go or did you consider making it a hybrid/micro kernel.
The monolithic/module thing was imposed by the subjects at my school (since it started as a school project).
However, a part of me is feeling like it could make sense to do a big refactor to turn all of this into a micro kernel. However I am not willing to do this until I have a plan to make it right.
By the way, the 32 bits thing too was imposed by the school. I am now wondering if it still relevant to support it and just support 64 bits only...