Re: kernel command line

[Roland McGrath]

> We don't need to rely on the PID 2 info:
> 
> /gnu/root/D1:    2    -  7  153M 9.67M  0:00.00  0:12.43 /boot/gnumach.gz 
> root=hd2s5
> 
> So, the kernel is clearly identified by the program name at least.

That is not really clean or robust.  I mean:

  (sh -c "exec -a /boot/gnumach.gz /bin/sleep 99999" & ps -wwl $! )

> If we want something better, we should make sure that it also works for
> sub-Hurds in the sense that I see the arguments to the boot command and not
> the arguments to the parent system.  It seems to make sense to provide an
> interface for the boot string in proc to query it then (and to set it, the
> already existing hack could be used).  The interface could be used by
> /proc/cmdline, or by a small C program.

The hostname is a similar case in the sense that no server in the system
needs to do anything with the information, it just needs to be stored
someplace.  In that case, we just use the /etc/hostname file, rather than
having any special protocol support for it.  I think the same sort of
solution is appropriate here.  Perhaps:

        msgport -p 1 --getenv MULTIBOOT_CMDLINE

That would be a good motivation for somebody to verify that the msgport
program (utils/msgport.c) actually works, and maybe write up a tutorial
that encourages people to use it for exploring what the message port is
about.  

This has the features you want, since init being PID 1 is something it is
reasonable to assume.  

> BTW, what output can we expect from a pstree on the Hurd? Will the hierarchy
> of a sub-Hurd shown in the parent system, or is this information lost?

No, there is no hierarchy of tasks in Mach.  The "parent" task on which the
task_create call was made is only used as the initial VM address space to copy.

Only proc keeps the notion of process hierarchy.  So, if there are two
Hurds then each one just sees all the other's tasks as "unregistered" tasks,
i.e. they show up in ps but you can't really do anything but kill -9 them.

I have previously considered adding a feature to Mach that would allow proc
to keep track of hierarchies of unregistered processes.  Then it could
assign each unregistered process the owner, pgrp, etc. of its nearest
registered ancestor process.  This should make it possible for non-root
users to run sub-hurds and debug or kill the sub-hurd tasks from the
original hurd.

Basically, there would be a send right associated with each task that you
can only fetch or set via the host privileged port, and which is copied
into new tasks by task_create.  proc would then set this port on each
registered task to something unique to that process that proc will
recognize later.  When proc comes across an unregistered task, it can
extract this port value and know what registered task created the mystery
task.  Then it can assign parent PID and propagate the owner uid and so
forth from the creator task.  When unregistered tasks create more tasks
before proc notices them, this might sometimes miss the intermediate
hierarchy.  But it will always attach unregistered tasks to either directly
or indirectly to the closest ancestor that is a normal Hurd process, and so
have a correct propagation of uids, if not an entirely accurate setting of
ppids.

> Where do I have to look to find out how proc is informed about arbitrary mach
> tasks that are not registered voluntarily?

proc/mgt.c:add_tasks.  When confronted with a task port not already in its
hash table, it asks the kernel (host priv port) for all the tasks in the
system and adds new tasks to its hash table.  This is when the PIDs are
assigned.