Re: 64bit GNU Mach

[Richard Braun]

On Sun, Apr 01, 2012 at 05:45:19PM +0200, Samuel Thibault wrote:
> I don't really see why there should be a "size of a pointer" property
> anyway: AIUI, vm_offset_t and vm_size_t are there for that. I rather
> see natural_t and integer_t as a "nice integer" type, i.e. something
> that can hold big enough values (e.g. >32bit), but not too big either
> (there is usually no point in having 64bit values), and thus the int
> type is "just fine". It is currently essentially used in RPCs to provide
> statistics, and for the RPC mechanism itself.

Kernel port names are addresses of their target IPC port object. There
are numerous occurrences of this in e.g. ipc/mach_msg.c or
ipc/ipc_kmsg.c. But it's an optimization and can be worked around. As
a simple solution, the kernel allocator could be tuned to return only
low addresses, so that natural_t could remain 32-bits (since userspace
is 32-bits), and keep the optmization inside the kernel. It would also
require some work on the IPC space table, since it's allocated using
VM functions.

> - The actual RPC mechanism however needs some decisions, notably the
> mach_port_t type.  For now it is a vm_offset_t type, and the kernel
> ipc mechanism will assume pointer alignment. Of course, 32bit userland
> will use a 32bit type and 32bit alignment there, so conversion will
> be needed. I've however noticed that there, xnu also simply used the
> natural_t type for port numbers, which is thus the same for 32 and 64bit
> builds, and saves a lot of headaches. I guess we don't really really
> need >2^32 ports anyway, so wouldn't it make sense to use a 32bit type
> too for a 64bit port?

I guess it's the preferable way. I'm not sure Xnu "chose" anything
there, as port names were early intended to be natural_t (because of
the optimization described above).

-- 
Richard Braun