bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64


From: Sergey Bugaev
Subject: Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64
Date: Tue, 2 May 2023 19:34:02 +0300

On Tue, May 2, 2023 at 7:08 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
>
> Sergey Bugaev, le mar. 02 mai 2023 18:47:50 +0300, a ecrit:
> > On Tue, May 2, 2023 at 6:20 PM Samuel Thibault <samuel.thibault@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.
>
> Not like hurd/boot?

You mean boot(1), which is at boot/ in the Hurd repo?

In that case, no, not like that at all. boot(1) is all about emulating
gnumach for the purpose of starting up a subhurd. It both provides
Mach devices (as passthrough, or Mach console device as its stdio) and
reimplements what Mach does when loading and starting the bootstrap
tasks. But after that it's off to the usual bootstrap dance (exet2fs
discovers it's the first task, does special stuff, helps exec start
up, spawns /hurd/startup, and so on).

> > it starts before anyone else, it implements a very basic in-memory fs
>
> tmpfs can be used for that.

It could, yes, but I also think this might be an overkill. I don't
think we'd need to store any file data, nor involve the default pager
or whatever. It'd only need to be usable as a "board" (or: "telephone
book" -- was the metaphor used somewhere in the Hurd docs I think?) on
which port names can be placed and looked up. So I'm thinking it would
be something simple, implemented with netfs.

These are the main ideas:
- provide / maintain "fs as a name service" during early boot,
reattach the same translators to the real root fs when it's up
- present a mostly normal looking environment to early bootstrap tasks
so they don't need any special handling, and more servers can be
repurposed as early boot tasks (note that once the bootstrap as done,
they keep running as just normal tasks), this would enable network
boot for example
- concentrate as much of early startup knowledge / specifics in the
bootstrapfs, stop/undo spreading it over everything
- get rid of /hurd/startup for good, or at least subsume as much of
its functionality as possible
- use the regular msg.defs facilities to publish services (rootfs,
proc, auth) as they come up -- again, no special modification
(fsys_init...) needed, this is already supported by glibc
- make all of this scriptable and hackable, using lisp if y'all so prefer

But given you're not yet screaming that this is a horrible idea, I
feel encouraged :D

Sergey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]