Re: [PATCH gnumach] Define rpc_vm_size_array_t and rpc_vm_offset_array_t

[Sergey Bugaev]

On Tue, Jan 31, 2023 at 10:54 PM Luca <luca@orpolo.org> wrote:
> I think it would be possible to handle both a 32-bit and a
> 64-bit userspace at the same time, as in XNU, but we'd need also
> user-space support if we want to integrate 32-bit and 64-bit tasks, and
> this seems a bit more complicated to me (although I have to admit, so
> far I know better the kernel part).
>
> Note that another way to handle the size conversion between rpc_* and
> regular types would be to add some new VM types to
> include/mach/message.h; in this case, the shrink/expand would happen in
> copyinmsg()/copyoutmsg() instead of the mig-generated code (as for mach
> ports), but this approach would require to plan for a staged
> introduction of this change.

Actually, yes, that's what I've been thinking about. Currently
vm_size_t & friends are conditionally (but statically) defined to
either MACH_MSG_TYPE_INTEGER_32 or MACH_MSG_TYPE_INTEGER_64. But what
if we also had MACH_MSG_TYPE_INTEGER_PTRSIZE (name TBD), which would
be equivalent to MACH_MSG_TYPE_INTEGER_{32,64} for {32,64}-bit tasks;
but the kernel would know about this and change its size accordingly
when transferring messages between 64- and 32-bit tasks. A value sent
as MACH_MSG_TYPE_INTEGER_32 is always received as
MACH_MSG_TYPE_INTEGER_32, no matter if the intent was to send a
pointer-sized value, whereas a 32-bit value sent by a 32-bit task as
MACH_MSG_TYPE_INTEGER_PTRSIZE would get received as a 64-bit value,
still MACH_MSG_TYPE_INTEGER_PTRSIZE, by a 64-bit task.

This would allow 32- and 64- bit tasks (including the kernel task) to
communicate transparently, without requiring separate rpc_* versions
of all the pointer-sized types. Possibly. Maybe. Uness there are a lot
of subtler details to this, which there of course are.

But I'm sure it has been a conscious decision to go with the current
design and not this way?

I'm also not arguing that mixing 32- and 64-bit tasks is worth
supporting. This was a hard requirement for OS X, since they had to be
able to run existing proprietary binaries unmodified. We build
everything from source, so just having all of the userland be 64-bit
(and fixing any issues we find on the way) sounds very viable. Using
32-bit win32 software via Wine has been the single reason to run
32-bit processes on my GNU/Linux system, but apparently that's now
changing too (WoW64). And I don't know how relevant using Wine on the
Hurd is anyway.

Thoughts?

Sergey