Subj : Re: Computer Broken
To   : apam
From : tenser
Date : Wed Sep 17 2025 12:21 am

On 15 Sep 2025 at 11:02p, apam pondered and said...
 
 ap>  > Honestly, it's probably not worth it, and if you've got a working
 ap>  > fat implementation, then no need to bother.  It may be interesting,
 ap>  > though!
 ap> 
 ap> Yeah, I'm not sure it'w worth it either - unless I'm wanting to learn how
 ap> FUSE works (which may be a good way to port file system drivers in the
 ap> future? hmm)

If you want to be able to work with the filesystem using the
host's complement of standard tools (text editors, grep, awk,
sed, all that good stuff) then yeah, I think that's a decent
want to go.  I'm not a _huge_ fan of FUSE myself (the Plan 9
way of using 9P for everything was conceptually a lot more
elegant) but hey, that's just me.

 ap> Finding the FatFS driver was great though, because it's already well
 ap> tested - having a filesystem that I can rely on means easier to find
 ap> other bugs.. it's hard to debug your programs when they don't even load
 ap> off the disk correctly!

Yup.  A stable place to stand is essential in order to use your
lever to move the world.

 ap> Are you still working on that Rust port of .... I can't remember the name
 ap> of that OS - was a unix os that got ported to RISCV i think...

I believe you mean rxv64, which was a Rust rewrite of xv6, but
retargeted to x86_64, instead of 32-bit x86.  I keep it working,
but that project is basically done.

I did that for a very specific purpose: we had a project where
we were working on a new hypervisor that ran directly on the
bare metal, and doing so in Rust.  The issue was that we had a
lot of people from Google cloud working on the project; all of
them were excellent software engineers, but mainly had experience
working in C and C++ at the application level on Linux, not at
the kernel level and not in Rust.  In order to ramp them up on
kernel development, we were pointing them at MIT's course
materials that used xv6; the feedback from that was "this is great,
but it's 32-bit specific and it's in C."  So I did rxv64 as an
additional resource; that was helpful, but it was always meant as
a pedagogical aid (and one for working engineers), not a production
system.

Still, elements of it have shown up in various places.  For instance,
the exception handling code for the production bootloader on the
Oxide machine is derived from rxv64:
https://github.com/oxidecomputer/phbl/blob/main/src/idt.rs

(We use it on the development bootloader/debugger, as well:
https://github.com/oxidecomputer/bldb/)

--- Mystic BBS v1.12 A48 (Linux/64)
 * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

.