[kelas]

(all points taken, all valid in their own right)

yes, riscv arch is a relatively new thing, which now quietly powers every modern nvidia gpu, led to a final demise of MIPS, and for whatever reason made MIT PDOS abandon x86 as their OS teaching platform back in 2018 (ask them why).

but perhaps i didn’t stress my central point enough, which is “textbook”. Xv6 used to have a make target which produced 99 pages of pdf straight out of C code. i don’t think the latest riscv release (rev3) still has it, probably because it is no longer deemed necessary - the code now documents itself entirely, and the tree is down to just kernel and user(land), both implemented in consistent and uniform style.

rxv6, at least its userland, still seems to be written in C, which (correct me if i’m wrong) must be creating a lot of pressure on the rust kernel along the lines of ‘unsafe’ and ‘extern “C”’.

i only hope the said group of pro engineers who needed to be ramped up on all of that at the same time plus the essentials of how an OS even works got ramped up alright.

again, no offense. and not to start a holiwar “rust will never replace C”. why not, maybe it will, where appropriate. which is why the notion of C++ is a sequitur all the way.

[cross]

> rxv6, at least its userland, still seems to be written in C, which (correct me if i’m wrong) must be creating a lot of pressure on the rust kernel along the lines of ‘unsafe’ and ‘extern “C”’.

Yes. I didn't feel the need to rewrite most of that. The C library is written in Rust, but as a demonstration, most of the userspace programs are C to show how one can invoke OS services. Are there unmangled `extern "C"` interfaces and some unsafe code? Yes.

Userspace interacts with the kernel via a well-defined interface: the kernel provides system calls, and userspace programs invoke those to request services from the kernel. The kernel doesn't particularly care what language userspace programs are written in; they could be C, Rust, C++, FORTRAN, etc. If they are able to make system calls using the kernel-defined interface, they should work (barring programmer error). Part of the reason rxv64 leaves userspace code in C is to demonstrate this.

The rxv64 kernel, however, is written in almost entirely in Rust, with some assembly required.

> i only hope the said group of pro engineers who needed to be ramped up on all of that at the same time plus the essentials of how an OS even works got ramped up alright.

They did just fine.

[kelas]

okay, fair. i only got misled by the title of the post, which claims all-rust xv6 port.

now that we cleared the userland part, here’s what I’m contemplating on the kernel side. i can’t think of anything simpler and more staple than this, so:

https://github.com/dancrossnyc/rxv64/blob/main/kernel/src/ua...

https://github.com/mit-pdos/xv6-riscv/blob/riscv/kernel/uart...

honestly - i don’t feel at ease to tell which driver code is more instructional, which is easier to read, which is better documented, which is better covered with tests, which has more unsafety built into it (explicit or otherwise), what size are the object files, and what is easier to cross-compile and run on the designated target from, say, one of now-ubiquitous apple silicon devices.

lest we forget that the whole point of it is “pedagogical”, i.e. to learn something about how a modern OS can be organized, and how computer generally works.

and i’m just not sure.

[cross]

Well, you're free to study both in detail and draw your own conclusions. But the UART driver in both is pretty uninteresting, and I suspect whatever conclusions one may draw from comparing the two will be generally specious.

Perhaps compare the process code, instead, and look at how the use of RAII around locks compares to explicit lock/unlock pairs in C, or compare how system calls are implemented: in rxv64, most syscalls are actually methods on the Proc type; by taking a reference to a proc, we know, statically, that the system call is always operating on the correct process, versus in C, where the "current" process is taken from the environment via per-CPU storage. Similarly with some of the code in the filesystem and block storage layer, where operations on a block are done by passing a thunk to `with_block`, which wraps a block in a `read`/`relse` pair.

Of course I'm biased here, but one of the nice things about Rust IMO is that it makes entire classes of problems unrepresentable. E.g., forgetting to release a lock in an error path, since the lock guard frees the lock automatically when it goes out of scope, or forgetting to `brelse` a block when you're done with it if the block is manipulated inside of `bio::with_block`. Indeed, the ease of error handling let me make some semantic changes where some things that caused the kernel to `panic` in response to a system call in xv6 are bubbled up back up to userspace as errors in rxv64. (Generally speaking, a user program should not be able to make the kernel panic.)

[kelas]

thanks, this is useful, let me ponder. obviously i am also a subject of severe cognitive bias, granted.

but ok, if not uart driver - what other direct comparison in r/xv6 kernel spaces you would use to show where rust shows a real hard edge over C?

not a loaded question, I’m seriously asking for a valid pointer (no pun intended)

[cross]

Sorry, I thought my last message did give suggestions for things to compare?