On Tue, Jan 31, 2023 at 10:54 PM Luca <l...@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