hurd: Get a startup server port from a file instead of a PID

  To allow easier implementation of different init systems, Hurd no
longer requires PID 1 to speak the startup protocol.  Ports to the
startup server are now obtained from /servers/startup instead.
---

Hi,

This patch has been included in Hurd's glibc branch and Debian's libc
for a while, and we'd like to have it applied upstream.

I haven't submitted copyright assignment papers for glibc, but I don't
believe this change is legally significant.  Let me know if I need to
take care of copyright assignment for this.

Thanks.

David

 ChangeLog                  | 6 ++++++
 sysdeps/mach/hurd/reboot.c | 5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)
  

Hi David!

On Thu, 18 Sep 2014 17:14:17 -0400, David Michael <fedora.dm0@gmail.com> wrote:
> On Wed, Sep 3, 2014 at 8:33 AM, Justus Winter
> <4winter@informatik.uni-hamburg.de> wrote:
> > Bind the startup server to /servers/startup instead.  Use this to
> > contact the startup server.
> 
> I'm trying to test this patch, and glibc appears to need an update as
> well.  Does this look okay?

Thanks for looking into this!

> --- a/sysdeps/mach/hurd/reboot.c
> +++ b/sysdeps/mach/hurd/reboot.c
> @@ -33,8 +34,8 @@ reboot (int howto)
>    if (err)
>      return __hurd_fail (EPERM);
> 
> -  err = __USEPORT (PROC, __proc_getmsgport (port, 1, &init));
> -  if (!err)
> +  init = __file_name_lookup (_SERVERS_STARTUP, 0, 0);
> +  if (init != MACH_PORT_NULL)
>      {
>        err = __startup_reboot (init, hostpriv, howto);
>        __mach_port_deallocate (__mach_task_self (), init);

When doing such changes, please try to be conservative.  For example,
until now, my system has been running "old-style", without
/servers/startup, and now I upgraded the glibc packages, then tried to
reboot, and it hung because of "invalid RPC".  Forcing a reboot -- root
filesystem has not been properly synced, and is now fried (unexpected
inconsistencies -- I'll try to repair).  That is, when doing such
incompatible changes, provide a smooth migration path: if the new call
fails because the RPC is not known (which is a dedicated error code),
then try the old way.  It then probably also makes sense to add a comment
to schedule the old way for removal at some point.  (And no worries about
my squashed root filesystem: of course I have it scripted -- mostly --
how to create a new one.)


Grüße,
 Thomas