Re: mach_port_t vs task_t (really ipc_space_t) in Mach header files

[Marcus Brinkmann]

On Fri, Sep 28, 2001 at 01:23:25AM +0200, Farid Hajji wrote:
>   * are the more specific types at least _consistently_ used?
>     I doubt this is the case: a lot of files simply fall back to
>     mach_port_t later
>   * are they really needed for architectural reasons, or, more
>     precisely, for better readability? In the Mach case, I'd
>     guess "maybe no," but on non-Mach VKs, that could well be
>     a different matter.

The story behind the specific types has to do with the intran/outtran
capability of MiG.  Take for example the auth server.  To some caller of
auth_getids, "auth_t handle" is just a genuine mach_port_t.  auth_t is just
a "typedef mach_port_t" (hurd/hurd_types.h).  However, the use of
auth_t is not entirely sugar.  In auth/authmutations.h you will find the
following code:

#define AUTH_INTRAN authhandle_t auth_port_to_handle (auth_t)

And in auth.c:
authhandle_t
auth_port_to_handle (auth_t auth)
{
  return ports_lookup_port (auth_bucket, auth, authhandle_portclass);
}

kern_return_t
S_auth_getids (struct authhandle *auth,
   ...

MiG will automatically call auth_port_to_handle on the port, and pass the
authhandle_t value as the first argument to the function rather than the
port.

So, an auth_t is a mach_port_t that matches a server-sode authhandle_t
object.  The same is true for other ports.  Like, a task_t is a port that is
connected with a kernel-side task structure.

Your questions are not easily answered.  What can be said is that for the
Mach IPC system, all ports are the same, and all messages too.  You can send
any message to any port.  So, there is no enforcement of those "types", not
even at run time, except the behaviour of the server if he receives an RPC
on a port (usually, if the lookup of the internal structure fails,
EOPNOTSUPP is returned, but that's not always the case).

I think it is interesting to ask the converse of your second question:
"Does anything in Mach or the Hurd rely on this polymorphic behaviour?" and I
don't know the answer.  It might be that some part of the Hurd relies on the
ambiguity and that enforcing the type match would break it.  However, I
can't think of anything specifically.   If there is nothing, you can make
ports strong typed without loosing anything.  Otherwise you will have to
demangle the ambiguities.

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