Re: [PATCH 03/17] Add proc_set_init_task, make runsystem pid 1

[Justus Winter]

Quoting Justus Winter (2013-08-29 12:09:02)
> Quoting Samuel Thibault (2013-08-29 01:48:10)
> > I think we should keep this in the Debian package, the upstream GNU
> > system will a priori still use /hurd/init as reaper.
> 
> Well, it is not my place to question this and maintaining the patches
> is your burden, but I was hoping to remove the process reaping code
> from /hurd/init.

I just spent about five hours debugging why my patched /hurd/proc
crashes early on in the boot process (and yes, I also used subhurds
and tried to hook gdb into it, it didn't produce any useful results,
not quite sure why). Turns out it was only because my /hurd/init
contained the proc_set_init_task patches while the /hurd/proc I built
on top of hurd upstream did not :/ and this was even though I wrote
those patches.

So I'd like to restate these questions:

1. Who is "upstream GNU"?

2. If I shall continue working on the Hurd, how suspectible is
   "upstream GNU" to my patches?

I ask this because I see the difference between "Hurd with Debian
patches" and "upstream Hurd" as a burden not only for the Debian
maintainers but also for any potential developer.

Also, according to [0] Debian/Hurd is the only "working" Hurd
distribution (whatever that means, let's say not in "early stages of
development" and not "defunct" as used on that page). In particular,
the "GNU" distribution is marked as "defunct" and according to [1]
there has not been a release for seven years. So from my point of view
they are *not* using /hurd/init as reaper, so they might as well *not*
use sysvinit (or any other established init system) as reaper.

0: http://www.gnu.org/software/hurd/hurd/running/distrib.html
1: http://www.gnu.org/software/hurd/hurd/running/gnu.html

Justus