Re: 64bit GNU Mach

[Samuel Thibault]

Richard Braun, le Mon 02 Apr 2012 12:03:34 +0200, a écrit :
> 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.

Inside the kernel, yes. In the userland processes, no. That's the
difference that xnu makes between mach_port_t (kernelland) and
mach_port_name_t (userland) (sorry I forgot to mention that in my
previous mail).

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

We can also rather simply fix the code that converts from names to
pointers into using different sizes, like xnu does.

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

They decided to split mach_port_t into mach_port_t and mach_port_name_t,
and cope with the size difference.

Samuel