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.thiba...@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