GSoC Project: Making Redox Self-hosting, Final Summary

By ids1024 on Tuesday, August 22, 2017

More details of what I’ve done are listed in the status reports I’ve written:

Summary of Progress Made

Since cargo does not work on Redox, it is fair to say that Redox is still not self-hosting. However, that shouldn’t be hard to fix once a couple kernel features that are currently blocking it are implemented. And I intend to help with that once those blocking issues are addressed.

However, in the mean time, I’ve found plenty of other things to work on by focusing on C software, such as making autotools builds work. I have succeeded with a basic autootools based build, though automake/autoconf themselves are not quite functional yet and more complicated builds tend to have issues. It was my intention from the beginning to work on various C porting issues once I had gotten the toolchain working. So I can’t quite say the project was a complete success, but I think overall enough progress has been made in various things, and real self-hosting should now be possible before too long.

Aside from being nearer to self-hosting, porting C software to Redox should be easier now. I have made many improvements to Redox’s C library, and addressed many POSIX incompatibilities. The amount of C software that runs on Redox has increased a fair amount.

What I Learned

A couple of the bugs I dealt with gave me an appreciation for printing integers in hex rather than decimal; things like byte order and address alignment become obvious. I’ve also come to realize that largely following POSIX is important for an OS; frankly, some aspects of POSIX don’t make sense or are outdated, but if you want to use existing software, it becomes rather important. Of course, not everything need be compliant; and the implementation is flexible (POSIX specifies APIs; not the kernel-level interface, or other details like that).

Nothing gives you an appreciation for debuggers like not having one; although that was only relevant to a couple issues I had. I was able to use a convoluted means to connect gdb to qemu and set a breakpoint. At some point Redox needs the ptrace system call or another tracing API; perhaps a scheme, because ptrace has a rather bad API. For debugging Rust, my PR implementing Rust backtraces on Redox should help.

Rust does seem like a suitable language of OS development. Hopefully even if Redox achieves nothing else, it will demonstrate the strength of Rust in this area.

Further Matters to Address

As mentioned before, interruptible system calls are needed to get cargo working, and there’s also an issue with thread joining. Once those are addressed, it should be easy to make progress on cargo builds.

When I patched Rustc, one awkward issue was the lack of dynamic linking on Redox. Various rustc components are built as dynamic libraries (I was able to statically link them) and procedural macros depend on dlopen (I added a hack disabling proc macros). So Redox needs a dynamic linker. Redox may use m4b’s dryad, which is written in Rust.

Once dynamic linking is possible, it should be possible to upstream Redox patches for rustc. Also, there are various other places where a dynamic linker would help; it would make it possible to load C modules in Python and Perl, for instance. Automake seems to depend on Perl’s dynaloader.

I intend to continue being involved in Redox, though I have other projects to work on, and may also want to work on other aspects of Redox.

Pull Requests

It would be convenient if everything was in one PR or repository, but due to the nature of my project, it touched various repositories. Here is a complete list of the pull requests I have filed related to Redox as part of the GSoC: