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
