On Tue, May 2, 2023 at 7:48 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > You'll need to store the /dev directory etc. And possibly some temporary > conf files for some translators, etc. Really, an initrd doesn't seem too > horrible a thing. Better maintain few powerful tools than a series of > small tools that then get lesser care.
There's not exactly much to store, you'd have a script that creates the few nodes we need (/servers/acpi, /servers/bus/pci, /dev/wd0) programmatically and starts/resumes the tasks meant to translate on them. But I'm not opposed to an idea of a full initrd either, it indeed could be useful if something required config, though I don't think there are currently any servers that do. But say resolving a hostname for network boot may require some config and nss modules and whatnot. > This will be just the fourth time that this part of the Hurd gets > reimplemented? > > I mean, I agree that some pieces can be added to the picture and things > be improved, but I see that part getting reimplemented by people having > great ambitions for it, and then it gets reimplemented again and again. Then perhaps you could tell me more about the history, so we can avoid repeating the mistakes of the past :) I'm vaguely aware that /hurd/startup was a full-blown init system some time ago (which explains some of its peculiarities), and then it was made to only do what is required to bring up enough of a Unix environment to then run a third-part init system. I'm aware of the bootshell proposal, but it seems to have never made it into the mainline Hurd. That letter also mentions that there was once a 'serverboot' which apparently did all the bootscript things that gnumach and boot(1) do now? Sergey
