On Tue, May 2, 2023 at 6:20 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote:
What I'm really interested in doing is 'bootstrapfs'... which is kind
of the same thing as the boot shell, but with a different focus.
Uhh, I need to put in the time to actually write one of those long
letters detailing what I have in mind; but here's an "elevator pitch":
it starts before anyone else, it implements a very basic in-memory fs
(*not* an initrd) which is sufficient to host filesystem nodes on
which translators can be installed (probably only /dev and /servers),
and it also implements some proc RPCs (maybe even the I/O RPCs to give
everyone working std{in,out,err}). It then starts everyone else, and
those all see a much less spartan environment than they do today, i.e.
they have a root filesystem port (to bootstrapfs), and they do things
much as they would normally do on a full booted-up Hurd system, not
with special early boot-up codepaths (libmachdev...).
Filesystem-as-name-service is maintained, in particular ext2fs can
just look up /dev/hd0 (or /dev/wd0), and everyone can lookup
/servers/bus/pci, and 9pfs will be able to look up /servers/socket/2
if you want boot-over-network (but you'll have to statically link
pfinet and add it to the boot script). When the real root fs is up,
bootstrapfs re-attaches all of the translators there and then
"publishes" the root fs port by sending msg_set_init_port to everyone.
Then it starts auth and proc and also publishes their ports in the
same way. In the end everything's connected properly and bootstrapfs
can quietly go away (or exec sysv init perhaps).
And hopefully all of this is scriptable and hackable and nice, because
all of the tricky logic is in one place (bootstrapfs), and everyone
else sees a mostly regular environment and may not even 'notice'
they're running as an early bootstrap task.
There are some subtle details here, and again, I need to write the
full version, but that's the idea.
Sergey
