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

[Roland McGrath]

> 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. 

Ports is ports.

> 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.

That is exactly what it's doing.  Each task always has one and only one
name for a port, no matter where the receive right is held (in the same
task, another task, or the kernel).  When you get more send rights to a
port you already have send rights to, you get the same name.  What else are
you expecting??


In reading the kernel code, I think you have missed some of the intricacies
of how ports are handled in the kernel RPC functions.  To give you precise
details, I would have to just go and read code and you can do that yourself.

Like in our userland MiG servers, ports are translated by the MiG
intran/outtran functions into server data structures.  In the kernel, that
is struct ipc_port.  That data structure stores everything about the port,
including where its receive right lies or whether it is a kernel object
(and then which flavor).

> 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.

I think

> 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).

You have misunderstood the flow of control.  If you use oskit-mach with gdb
over a serial line, then you can step through the code paths of the IPC
code looking at the source code (using gdb in emacs, of course) and see
what is really going on.  Hint, hint.

> 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.

Yes, you are indeed confused. :-) This is not the kind of thing I would
expect to find much documentation on, you just have to get to know the code
more fully.  

zones are simply a memory allocator, that is all.  Which zone you allocate
from just has to do with which pool of kernel memory gets used up, whether
it is physical or virtual memory, etc; and the zone parameters are
optimized for a particular kind of data structure.  There is nothing at all
magic about it.