Linux's VGEM Kernel Driver Being Rewritten In Rust

[Developer12]

Not really. It is a fairly common step in a language to write the compiler in the language itself after a point. Go did this a few years back for example.

If you want really crazy, legend has it there's an effort to write a new C compiler and toolchain entirely in rust. How the tables turn.

[Jabberwocky]

Are there any ARM-based Apple laptops that have working input, display, graphics, power management in Linux?

[aht0]

I see several ways it could end up in an incomplete migration:
- Friction with some more reluctant developers (not everyone is on board with Rust AFAIK), some of whom may be maintainers (so they have a call about whether or not Rust makes it into their subsystem).
- Some parts are simply not worth the extra effort, say, several architectures and drivers have had only minor bug fixes and corrections to fit interface changes for years. I don't think they will drop them only to avoid migrating them to Rust, as long as they don't get in the way of migrating the rest.
- Some parts may either be deemed too sensitive for a rewrite or it may simply not be that beneficial for that case to migrate to Rust (say, trivial code that you can really be sure has no memory safety/UB bugs).

I think stuff will be migrated on an as-needed (particularly buggy areas) and/or opportunistic (no need to keep doing new development in C) basis, rather than just go all in.

Agreed. More likely to happen in DragonFly, less devs (seen about 10 commiting/fixing bugs), less possible friction. But they also seem fixed on C.
John Marino's Synth (written in Ada) was re-impemented into DragonFly as an OS's integral utility in C. Still kinda buggy and some features missing :/

Seeing Linux rn more forward-thinking..

[kpedersen]

If you want really crazy, legend has it there's an effort to write a new C compiler and toolchain entirely in rust. How the tables turn.

Arguably a compiler is one thing that Rust *should* be able to do without pulling in a bunch of C binding layers from crates.io.

After all, a compiler has very simple IO. It takes plain text files and emits binary files. It shouldn't depend on any of the underlying operating system (where Rust is fairly weak at interfacing against).

If you can do it in Javascript, you can probably just about do it with Rust.

[RahulSundaram]

If you want really crazy, legend has it there's an effort to write a new C compiler and toolchain entirely in rust. How the tables turn.

No such effort exists of course. a) mrustc (entirely in C++) and GCC RS (reusing Rust libraries outside of the compiler) are written in C++ as I have noted earlier in the thread b) Even if there was an effort, C is a pretty common language to write compilers. Google's Go compiler itself was originally written in C and Python's reference compiler, CPython continues to be written in C today as the name indicates although alternatives like pypy are self hosting.

[sinepgib]

They may have a call, but if they unreasonably restrict rust due to philosophical reasons they may find that others may end up being the subsystem maintainers.

There are logical reasons to restrict Rust though. As with pretty much everything in engineering, there is a tradeoff and different programmers will tilt toward different decisions. For example, lifespan is a reasonable argument: compared to C, Rust is young, which means C is a (slightly, IMO) better bet for expecting it to be around in 20-30 years from now, simply because it already lived such long times.

Some parts of the kernel will always be so low level architecture specific that assembly may be the best approach, but if the code is trivial, migrating to rust may be low hanging fruit that may be chosen precisely because it is trivial (starting simple is commonly considered a good approach (was not almost everyone's first C program "Hello World"?)).

Yeah, I don't know how I missed this part really, as it is the most obvious one. But the parts that absolutely need assembly language tend to be few and small and are already not C (I mostly assume we only mean to rewrite the C parts, I may be wrong). Some will also be kept as assembly for performance, the sufficiently smart compiler that vectorizes complicated algorithms isn't yet here AFAIK.

[sinepgib]

Are there any ARM-based Apple laptops that have working input, display, graphics, power management in Linux?

All of them AFAIK. Asahi gives a good OOB experience. Maybe power management is not supported, and while graphics are supported accelerated graphics are still WIP. Very off-topic question though.

[darkonix]

Arguably a compiler is one thing that Rust *should* be able to do without pulling in a bunch of C binding layers from crates.io.

After all, a compiler has very simple IO. It takes plain text files and emits binary files. It shouldn't depend on any of the underlying operating system (where Rust is fairly weak at interfacing against).

If you can do it in Javascript, you can probably just about do it with Rust.

That's only valid for small compilers. You can write those in most languages in a relatively simple way. As you add more complexity it make more sense to reuse code. C has a culture of not reusing external libraries because of historical & technical reasons. Modern languages don't have the same culture so they encourage reuse more and make it easy to do so.

[Almindor]

There are logical reasons to restrict Rust though. As with pretty much everything in engineering, there is a tradeoff and different programmers will tilt toward different decisions. For example, lifespan is a reasonable argument: compared to C, Rust is young, which means C is a (slightly, IMO) better bet for expecting it to be around in 20-30 years from now, simply because it already lived such long times.



Yeah, I don't know how I missed this part really, as it is the most obvious one. But the parts that absolutely need assembly language tend to be few and small and are already not C (I mostly assume we only mean to rewrite the C parts, I may be wrong). Some will also be kept as assembly for performance, the sufficiently smart compiler that vectorizes complicated algorithms isn't yet here AFAIK.

I bet COBOL was in the same ship as C is now, albeit with much less actual software written in it.

As for the assembly, yes there are a few places where it is needed. The initial runtime setup needs to be in assembly for example (because basic memory isn't even "set up" yet e.g. stack pointer or frame pointer). The nice thing about doing these in Rust though is that you minimize the asm surface as much as possible, link it together and unsafe only things like CSR access, preferably with very well tested generated code.

Most other things can then be safe rust which makes for great safety guarantees.

[Developer12]

No such effort exists of course. a) mrustc (entirely in C++) and GCC RS (reusing Rust libraries outside of the compiler) are written in C++ as I have noted earlier in the thread b) Even if there was an effort, C is a pretty common language to write compilers. Google's Go compiler itself was originally written in C and Python's reference compiler, CPython continues to be written in C today as the name indicates although alternatives like pypy are self hosting.

This effort exists but has not been publicly announced to my knowledge.

I am not talking about a rust compiler. I am talking about a standards-compliant compiler that compiles C code and has been written in Rust.