Re: [PATCH gnumach] Define rpc_vm_size_array_t and rpc_vm_offset_array_t

[Sergey Bugaev]

Replying to myself after looking at the definition:

On Tue, Jan 31, 2023 at 12:06 PM Sergey Bugaev <bugaevc@gmail.com> wrote:
>
> I understand they are related to the x64 bringup, and possibly to
> running 32-bit userland on a 64-bit kernel (or to support for 32-bit
> tasks communicating with 64-bit tasks?).

It's hust for running 32-bit userland on 64-bit kernel (USER32).
Mixing 32- and 64-bit tasks on the same system does not seem to be
supported at all, and in fact you must build the Mach with USER32
either defined or not, you cannot have it both ways. Unlike in XNU.

> But how are they different to
> plain vm_size_t etc,

When running in full/native 64- (or 32-) bit mode, both rpc_vm_size_t
and vm_size_t will be of the same, well, size. But with USER32,
vm_size_t will be 64-bits wide, while rpc_vm_size_t will be 32-bits
wide. In other words, rpc_vm_size_t is "the userspace's idea of
vm_size_t".

> and when am I supposed to use one vs the other?
> Does this only concern kernel land (i.e. GNU Mach) or the userland
> too?

In userland, always use the regular variants. In MIG defs, use the
rpc_*variants. For the most part, MIG will handle the conversion
automatically (intran: vm_address_t
convert_vm_from_user(rpc_vm_address_t) and the like), so the
KernelServer routines can use the regular types already. That is,
except for particular cases like this one, where we have an array of
offsets/sizes which of course cannot be just converted in-place.

Did I get it right?

Sergey