64bit GNU Mach

[Samuel Thibault]

Hello,

Some weeks ago, I have worked a bit on a 64bit version of GNU Mach. I
hvae of course cherry-picked some of the work of Guillem. This is all in
the master-x86_64 branch. Only Xen platform is supported (I didn't want
to spend time on the bootstrap issue, and it's easier to debug).

Note: I'm talking about kernel 64bit support only, userland would
remain 32bit for now.

Basically, it is working, up to the point where ext2fs.static starts
making RPCs, and now the 32/64 compatibility RPC issue raises, in
addition to a type question.

- in my tree, integer_t is left as int type, while Guillem made it a
long. I have left it int mostly for least surprise. Also because Apple's
xnu did it too, with the following explanation:

/*
 * natural_t and integer_t are Mach's legacy types for machine-
 * independent integer types (unsigned, and signed, respectively).
 * Their original purpose was to define other types in a machine/
 * compiler independent way.
 *
 * They also had an implicit "same size as pointer" characteristic
 * to them (i.e. Mach's traditional types are very ILP32 or ILP64
 * centric).  We support x86 ABIs that do not follow either of
 * these models (specifically LP64).  Therefore, we had to make a
 * choice between making these types scale with pointers or stay
 * tied to integers.  Because their use is predominantly tied to
 * to the size of an integer, we are keeping that association and
 * breaking free from pointer size guarantees.
 *
 * New use of these types is discouraged.
 */

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.

- About 32/64 RPC compatibility. For userland RPCs, things will of
course be just fine. For RPCs served by the kernel, the content of the
RPCs should be fine: mig can probably be patched to support conversion.

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

Samuel