Replying to myself after looking at the definition: On Tue, Jan 31, 2023 at 12:06 PM Sergey Bugaev <buga...@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