Live data from Hacker News

Maestro: A Linux-compatible kernel in Rust

blog.lenot.re

191–200 of 380 posts

Re: Maestro: A Linux-compatible kernel in Rust

#191

Earlier quoted context omitted.

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 t…

Unless you are building your own custom kernel (ie gentoo) CPU specific optimizations are not worth it as they are worse for any other CPU even if the code is still run. Most software never had those micro optimizations applied, because most software wants to have one build that runs any many different CPUs, but if you want to make an exception it is still possible with compiled code.

While you can write those micro optimizations for each CPU by hand, they not worth the human cost except in very rare situations. In most cases of course you can't measure the difference, as only a couple CPU cycles are saved.

Re: Maestro: A Linux-compatible kernel in Rust

#192

Earlier quoted context omitted.

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.

Even if this is true, which I agree it is, it’s still a 100x more painful than writing a programming language and compiling to RISC-V. That also gives you the benefit of compiling to multiple arch’s

Re: Maestro: A Linux-compatible kernel in Rust

#193
post #82

Some words of encouragement in the sea of pessimism on HN which brought down the previous attempt at this [0]. Keep going, ignore the FUD and continue where others have left off. We need alternative and safer kernels, and attempts like this should be encouraged. Rust is suitable for that guarantee. Keep going. [0] https://news.ycombinator.com/item?id=28986377

Thank you very much! Even if nobody liked the project, I would not be planning to stop it. I am doing this as a hobby first!

Having even one other user than me would be terribly difficult but if it happens that would be super cool! If it does not happen, then I just have my own system and I am happy with it anyways!

Re: Maestro: A Linux-compatible kernel in Rust

#194

A 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…

[deleted]

Re: Maestro: A Linux-compatible kernel in Rust

#196
post #69

Earlier quoted context omitted.

I like Rust and work in it fulltime, and like its memory-safety aspects but I think it's a bit of a stretch to be able to claim memory safety guarantees of any kind when we're talking about low-level code like a kernel. Because in reality, the kernel will have to do all sorts of "unsafe" things even just to provide for basic memory management services for itself and applications, or for interacting with hardware. You…

Yep. And tooling to secure C improved a lot in recent years. The Address-Sanitizer is a big improvement. I’m looking forward that C++ improves as language itself because it was already improved (smart-pointers, RAII, a lot of edge cases regarding sequencing) and they seem to be willing to modify the actual language. This opens a path for project to migrate from C to C++. A language inherits a lot from its introductio…

One of the inspirations for Rust, as I recall, was Cyclone: https://cyclone.thelanguage.org/

Which was/is a "safe" dialect of C; basically C extended with a bunch of the stuff that made it into Rust (algebraic datatypes, pattern matching, etc.) Though its model of safety is not the borrow checker model that Rust has.

Always felt to me like something like Cyclone would be the natural direction for OS development to head in, as it fits better with existing codebases and skillsets.

In any case, I'm happy to see this stuff happening in Rust.

Re: Maestro: A Linux-compatible kernel in Rust

#198
post #156

Earlier 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).

What makes RISC-V special here? You speak as if RISC-V has some fundamental differences that invalidates old limitations that keep us trapped. Why is this the case? I'm very curious, and don't understand. Also, why does preprocessing matter so much?

RISC-V is a real free, worldwide standard for a modern and good enough ISA, and that changes everything, namely "moving forward" is not going to be the same than in a legacy context with those locked, non free ISAs.

Preprocessing does matter because it would be pointless to get rid of the compiler complexity to get instead preprocessing complexity.

For instance x86_64 assembler fasmg has the most powerful preprocessor out there.... because the assembler is actually written using this preprocessor language! So it is very easy to "slip" and to end up using excessively this prepropressor to actually write assembly code which is not an assembler!

Re: Maestro: A Linux-compatible kernel in Rust

#200

Earlier quoted context omitted.

"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 t…

Unless you are building your own custom kernel (ie gentoo) CPU specific optimizations are not worth it as they are worse for any other CPU even if the code is still run. Most software never had those micro optimizations applied, because most software wants to have one build that runs any many different CPUs, but if you want to make an exception it is still possible with compiled code. While you can write those micro…

This is what I just said. Then we agree on that matter.
Post reply on HN