Split /hurd/init into two programs (was: upstream GNU Hurd vs Debian GNU Hurd?)

[Justus Winter]

Hi :)

ok, getting back on topic:

Quoting Thomas Schwinge (2013-09-10 20:36:42)
> > /hurd/init is not an init system, it barely does anything any other
> > init system does. From my point of view its name is the only thing
> > that it has in common with other init systems, and it should really be
> > named /hurd/startup or /hurd/bootstrap or something as it really
> > mostly bootstraps a couple of processes running atop of mach into
> > something resembling a POSIX system. If GNU wants a sysvinit
> > replacement, they will have to write one.
> 
> I'm certainly not disagreeing with you.  What you're seeing there, as I
> understand it (I have not been around myself back then), in principle is
> some infrastructure to cobble the whole system together, so that one can
> indeed boot a GNU Hurd system.  From my point of view, this stuff
> (perhaps aside from the Hurd server startup/bootstrap) is not part of the
> the GNU Hurd project, but instead some separate package(s): an
> init/daemon management system, startup scripts, and whatnot.  Clearly an
> init system may be doing some things differently on the Hurd than it does
> on a "regular" Unix system, but it doesn't have to; its the init system
> implementor's choice.  The stuff shipped with the GNU Hurd for me is not
> meant to provide all that, but instead I consider the GNU Hurd to just be
> the Hurd interfaces (RPC definition files), and their implementation in
> the Hurd libraries and Hurd servers, and the integration work (such as
> init system, or package management) to be done externally.
> 
> So if you say /hurd/init is confusing and should be renamed/reworked
> (including removing functionality it currently provides) to, say,
> /hurd/bootstrap, then that is a valid proposal to be considered.  (I have
> not yet been able to look at this discussion myself.)

I propose to split /hurd/init into /hurd/startup and /hurd/init. I
mentioned it today in #hurd as something that could be done well
within the last week of the gsoc. Samuel suggested that I write about
that on the list to get the discussion rolling again before I even
start.

/hurd/startup would be the early bootstrapping code, getting proc and
auth up and connected, frobnicate the kernel, that kind of stuff. It
also handles the shutdown notifications. It is called startup because
it speaks the startup protocol.

/hurd/init is what's left, the signal handling and reaping. It is
started by /etc/hurd/runsystem.sysv like it would start sysvinit. It
spawns a single process running /etc/hurd/runsystem.gnu minus the part
that is already done in
/etc/hurd/runsystem.sysv. /etc/hurd/runsystem.{gnu,sysv} could then of
course be renamed to something more appropriate, the point being that
the common code could be shared between the runsystems in some way.

That way, Samuel could merge the "Add proc_set_init_task, make
runsystem pid 1" patch and GNU Hurd could still boot without sysvinit
just as before.

Thoughts?
Justus