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

[Samuel Thibault]

Sergey Bugaev, le mar. 02 mai 2023 17:10:17 +0300, a ecrit:
> On Mon, May 1, 2023 at 8:43 PM Samuel Thibault <samuel.thibault@gnu.org> 
> wrote:
> > > How do we proceed? I don't know enough about rump to get it building;
> >
> > We can easily cross-build debian packages thanks to the rebootstrap
> > scripts from Helmut:
> >
> > https://salsa.debian.org/helmutg/rebootstrap.git
> 
> I didn't just mean the build system; I'm not familiar with rump at
> all. I hardly understand what it is, other than it's some code
> extracted from NetBSD and intended to somehow be embeddable in a broad
> range of environments. I've skimmed their whitepapers, but I still
> don't have any idea how they accomplish what they are claiming to.
> 
> So I'm clearly not the right person to port rump to x86_64-gnu. Unless
> you're saying that it's largely architecture-independent and will just
> build.

It should be largely arch-independent (or ported).

> I was secretly hoping that the Linux drivers won't be fully abandoned
> with the rise of rump and lwip;

They are more than oldish. We really don't want to keep them.

> but that Linux and non-Linux implementations will both stay as
> available alternatives. And that someone would upgrade the bundled
> Linux code (6.3 is out now...) -- perhaps a future project for myself.

Really, don't spend time on that, Linux is a *way* too evolving target.

Been there, seen it tried both. Don't try to do that (TM).

> > Now, that being said, you can also use an initrd, see debian's
> > 50_initrd.patch (which nobody has yet taken the time to clean according
> > the discussion at the time). That's enough to run a full Hurd system,
> > you can for instance take the initrd files from the debian installation
> > CD.
> 
> Yes! An initrd sounds exactly like what I need, thank you!
> 
> Well, I'm unlikely to need whatever Debian is putting there, but the
> idea of a ramdisk, I mean.

Yes, and a working example.

> As for the best way to implement this... I have always thought gnumach
> should have a bootscript directive to expose a multiboot module as a
> memobj. Then there would be a task, /hurd/ramdisk, that would expose
> it over the device (and possibly I/O) protocols:

That was the idea discussed at the time... That nobody took the time to
implement so far.

Samuel