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

[Sergey Bugaev]

On Tue, May 2, 2023 at 8:56 PM Samuel Thibault <samuel.thibault@gnu.org> wrote:
>
> Sergey Bugaev, le mar. 02 mai 2023 19:34:02 +0300, a ecrit:
> > 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?
>
> Yes: it's precisely doing "Super ideally, gnumach wouldn't even know how
> to parse bootscripts and load ELFs; that, too, should be done by some
> pre-init task". It can also be used for sub-hurds by supporting device
> ports etc., but whatever can do a lot can also do a little.

Ah in that sense yes, exactly like what boot(1) does.

These are two separate ideas that have to be reconciled: one, that it
would be nice to have bootscript parsing and execution and ELF loading
to happen outside of the kernel, and the other, that the part of the
bootstrap that's already done in userspace today could be radically
improved. I think/hope that they could fit nicely together, maybe both
belong in the same bootstrap task (and maybe I need to learn more
about serverboot and bootshell to understand how), but they are
independent. Sorry if I wasn't clear enough about this; I just said
that the first one should be considered in the context of the second
one and then jumped to describing the second one, and interpreted your
question in the context of that and not the first one.

> Overall it's nice to have crazy ideas about making the boot flexible
> and all that, but as it is now it does work, and we also need to have a
> system that is relevant, i.e. that has some of the basic support that
> people would expect, such as broad network/disk support, USB etc.

Yes, I understand. I'm not proposing we break anything that works. If
I ever get to implementing this, of course I'll ensure that it works
at least as well as what we have now before proposing it for
upstreaming.

I don't see how network/disk/USB are relevant -- but it should be
easier, not harder to get new combinations of servers (as may be
required for booting from specific hardware) working under my plan.
You wouldn't need to adapt each and every server to run as an early
task, port to libmachdev, accept/handle special bootstrap argv
options, etc etc, you'd more or less just recompile with -static and
edit the bootscript.

Sergey