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

[Marcus Brinkmann]

On Fri, Sep 28, 2001 at 02:05:20AM -0400, Roland McGrath wrote:
> The reason for the types in .defs files is for intran/outtran.  I would
> tend toward using the specific types generally, because that has more of a
> chance to be mapped source-compatibly in some other RPC system.

I am doing this right now where feasible (like, I am doing it for host_t,
but not for mach_port_name_t, esp as there is no typedef for the latter ;)
It's only used internally to mark a MACH_MSG_TYPE_PORT_NAME parameter).

But I am uncertain, as the interface definitions explicitely set the
"ctype" to mach_port_t (that's what MiGs makes to put this type in the
header).  Maybe we should go and change those interface definitions were we
prefer the specific types without ctype parameter?  I am thinking of

thread_t
task_t, vm_task_t, ipc_space_t,
host_t,
host_priv_t,
processor_t,
processor_set_t,
processor_set_name_t,
memory_object_t,
memory_object_name_t,
memory_object_control_t,

in mach_types.defs.  Removing the ctype paramter in these places would
make MiG to put the specific type in the header file prototype for the user
rather than mach_port_t.  This would make me feel better with using the
specific type in the documentation as well.  This would be consistent with
what we do in the Hurd definition files, and as far as I can see there is
nothing to worry about source or binary compatibility in any way.

Oh, btw, we have two examples of subtyping here: vm_task_t and ipc_space_t
are really task_t.

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