Re: mach_host_self() doesn't acquire new port name?!

[Marcus Brinkmann]

On Sun, May 06, 2001 at 04:46:45PM -0400, Roland McGrath wrote:
> > I don't understand why mach_host_self() doesn't acquire a new port name and
> > leaks a port if not deallocated. In other words, I expected the following to
> > leak ports, but it doesn't:
> > 
> > main ()
> > {
> >   while (1)
> >     mach_host_self();       /* Returns 23 on each and every call. */
> > }
> 
> I don't know why you would expect different from that call.  It is
> returning a send right to the same port, so of course you get the same name
> for adding more urefs to the same send right in the same task.

Well, it seems that mach_host_self() is rather special in that it refers to
a kernel object (port in the kernel name space) rather than an object from
another user task. I didn't expect it to just increase the uref and return
the port number, as I don't own the receive port.  I expected it to work the
same as if the kernel was just another user task with its own distinct 
namespace.

But now I take a closer look at mach:/kern/ipc_host.c (ipc_host_init), where
the host name port is created with ipc_port_alloc_kernel/ipc_kobject_set.
I am a bit confused by the io_lock_init stuff, but it seems that in this
case, ip_object is not set (instead, ip_kobject is set with
ipc_kobject_set), so it is not valid, and IP_VALID(sright) in 
ipc_port_copyout_send
will not be true.

But I made the assumption that it is true because I did ignore any small
hint I might have caught about kobject and just thought about the kernel as
another user task.

With IP_VALID(sright) not true, the whole copyout_send is reduced to:

name = (mach_port_t) sright;

which of course explains why there is no new port name: Because there is no
real copyout!

So is it true that port 23 (in my case above) is the host name port for all
tasks of the system? It must be, as realport.host_self is a global, and it
is passwd through as the mach port (although it is an ipc_port_t).

What I don't understand yet is how it is made sure that there is no
collision between normal port names and those special port names
(Would it make sense to name them disembodied kernel receive rights?)
I traced it down to the use of zalloc in the definition of io_alloc, but I
don't know how this zone stuff works (is an ipc_port_t in the same zone as a
mach_port_t? This might explain it?). In face, I don't really understand
anything I am saying here, I am just reading my way through the code and try
to follow. It doesn't help that those kernel specialities don't appear to be
documented in the kernel principles/kernel interface mach docs.

Does my confusion make some sense now?

Maybe I should try to get hold of archivals of mach newbie mailing lists...

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de