/Real hardware breakthroughs, and focusing on rustc

Real hardware breakthroughs, and focusing on rustc

By jackpot51


System76 Galago Pro (galp3-c) running Redox OS.

After the addition of the
NVMe driver a couple months ago,
I have been running Redox OS permanently (from an install to disk) on a
System76 Galago Pro (galp3-c),
System76 Open Firmware
as well as the un-announced, in-development, GPLv3
System76 EC firmware
. This particular hardware has full support for the
making it easy to use with Redox.

This particular machine has had a
debugging port
soldered on, using the unused CEC pin of the HDMI port as RX, and then a custom
HDMI to USB serial cable for closed-chassis debug. Now I can get serial output
from the board, using the Intel LPSS UART on the PCH, which is supported in
this commit to the kernel,
an earlier commit fixing memory-mapped serial ports.
This has allowed for easier debugging of the kernel and drivers.

I am fairly satisfied with how things are going, and will continue to focus on
running a permanently installed Redox system. My work on real hardware has
HiDPI support
to a
number of applications,
and spawned the creation of new projects such as
to make it easier to
install Redox from a live disk.

It has also become easier than ever to cross-compile for Redox, with the
redoxer tool
which can build, run, and test using commands similar to cargo. It automatically
manages a Redox toolchain and can run executables and tests for Redox inside of
a container on demand.

However, a long-standing issue (the longstanding issue?) of Redox OS has been
this: To allow the compilation of Rust binaries on Redox OS.

Attempts have been made in the past to address this issue. In 2017, Redox OS
participated in the Google Summer of Code. Through the
excellent work done by ids1024,
Redox OS was able to get close to self-hosting. This work was then amplified by
the creation of a C library written in Rust,
relibc. Subsequent work by
over 40 contributors
has led to significant POSIX C library compatibility, and a significant increase
in the
number of available packages.

Work was later done to
convert Redox OS to a different Rust target family,
finally unifying Rust support for Redox OS with that of other Unixen. Finally,
Redox specific support code could largely be eliminated from codebases. This led
to a great number of Rust crates suddenly gaining Redox OS support.

It seemed that as though the dream of self-hosting would soon be reality. After
many heartbreaking hours (days, weeks, months?) of compiling rustc, then finding
some error requiring more work in relibc, I was finally able to compile a
statically linked rustc – only to discover that rustc is no longer capable of
running statically linked!

Then began work on relibc’s
which provides dynamic linking support for executables. Tragically, the work to
support dynamic linkage in Rust for Redox OS defaulted everything to dynamic
linkage, which took some time to sort out properly. This is where work was
halted on porting rustc to Redox OS.

Building Redox OS on Redox OS has always been one of the highest priorities of
the project. Rustc seems to be only a few months of work away, after which I can
begin to improve the system while running on it permanently, at least on one
machine. With Redox OS being a microkernel, it is possible that even the driver
level could be recompiled and respawned without downtime, making it incredibly
fast to develop for. With this in place, I would work more efficiently on
porting more software and tackling more hardware support issues, such as
filling in the USB stack and adding graphics drivers.

But, more importantly than what I will be able to do, is the contributions by
others that will be unlocked by having a fully self-hosted, microkernel
Operating System written in Rust, Redox OS.

As a bonus for reading the whole post,
here is the Redox OS boot time with an NVMe drive.

Discuss this post on:
Reddit /r/redox
Reddit /r/rust
Hacker News

Original Source