The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Jay Logue via TUHS <tuhs@minnie.tuhs.org>
To: tuhs@minnie.tuhs.org
Subject: [TUHS] retro-fuse project
Date: Mon, 22 Feb 2021 08:41:17 -0800	[thread overview]
Message-ID: <20210222164738.7381E93D39@minnie.tuhs.org> (raw)

Lately, I've been playing around in v6 unix and mini-unix with a goal of 
better understanding how things work and maybe doing a little hacking.  
As my fooling around progressed, it became clear that moving files into 
and out of the v6 unix world was a bit tedious.  So it occurred to me 
that having a way to mount a v6 filesystem under linux or another modern 
unix would be kind of ideal.  At the same time it also occurred to me 
that writing such a tool would be a great way to sink my teeth into the 
details of old Unix code.

I am aware of Amit Singh's ancientfs tool for osxfuse, which implements 
a user-space v6 filesystem (among other things) for MacOS.  However, 
being read-only, it's not particularly useful for my problem.  So I set 
out to create my own FUSE-based filesystem capable of both reading and 
writing v6 disk images.  The result is a project I call retro-fuse, 
which is now up on github for anyone to enjoy 
(https://github.com/jaylogue/retro-fuse).

A novel (or perhaps just peculiar) feature of retro-fuse is that, rather 
than being a wholesale re-implementation of the v6 filesystem, it 
incorporates the actual v6 kernel code itself, "lightly" modernized to 
work with current compilers, and reconfigured to run as a Unix process.  
Most of file-handling code of the kernel is there, down to a trivial 
block device driver that reflects I/O into the host OS.  There's also a 
filesystem initialization feature that incorporates code from the 
original mkfs tool.

Currently, retro-fuse only works on linux. But once I get access to my 
mac again in a couple weeks, I'll port it to MacOS as well.  I also hope 
to expand it to support other filesystems as well, such as v7 or the 
early BSDs, but we'll see when that happens.

As I expected, this was a fun and very educational project to work on.  
It forced me to really understand what was going in the kernel (and to 
really pay attention to what Lions was saying).  It also gave me a 
little view into what it was like to work on Unix back in the day.  
Hopefully someone else will find my little self-education project useful 
as well.

--Jay


             reply	other threads:[~2021-02-22 16:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 16:41 Jay Logue via TUHS [this message]
2021-02-22 17:10 ` Will Senn
2021-02-22 20:13   ` Rob Pike
2021-02-22 20:40 ` Anthony Martin
2021-02-24 16:01 ` arnold
2021-02-24 17:40   ` Brad Spencer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210222164738.7381E93D39@minnie.tuhs.org \
    --to=tuhs@minnie.tuhs.org \
    --cc=jay-tuhs9915@toaster.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).