| |||||||||||||
The hazards of 32/64-bit compatibilityThe hazards of 32/64-bit compatibilityPosted Sep 23, 2010 11:18 UTC (Thu) by michaeljt (subscriber, #39183)Parent article: The hazards of 32/64-bit compatibility
This may be a silly question (especially at this stage), but how hard would it be to do more of the 32bit/64bit compatibility in user space? Like say, would a special C library for mixed systems work? I realise of course that anyone doing their own system calls would probably also need some fixing, but people who do that sort of thing should be capable of handling it.
(Log in to post comments)
The hazards of 32/64-bit compatibility Posted Sep 23, 2010 13:46 UTC (Thu) by nelhage (subscriber, #59579) [Link]
In order to run 32-bit code, the userspace process has to run in 32-bit compatibility mode at the hardware level -- this is a setting on x86_64 processors to temporarily emulate 32-bit processors. So the kernel needs at least that much support, since I believe entering and exiting compatibility mode is a privileged operation.
You could potentially imagine doing the syscall 32/64 marshalling in user space, but you have the problem that unless you do something really clever and/or scary, that marshalling has to run in 32-bit mode because of the above fact, even though it's trying to talk to 64-bit kernel interfaces. Since the 64-bit kernel interfaces rely on using e.g. the full 64-bit registers, this is probably impossible.
You could perhaps have some new interface that accepts 64-bit data, but in a form accessible to this 32-bit shim layer, but there would almost certainly be a performance cost associated.
There are other problems, too, such as this shim having to know about virtually every ioctl in the kernel, something that would be nigh-impossible to keep up to date.
The hazards of 32/64-bit compatibility Posted Sep 23, 2010 15:01 UTC (Thu) by avik (guest, #704) [Link]
Switching modes is not a privileged operation; all it takes is a far jump (setting up the segment for the jump _is_ a privileged operation).
AFAIK the Windows kernel does not support 32-bit entries at all; the compatibility code is completely in userspace.
The hazards of 32/64-bit compatibility Posted Sep 23, 2010 16:01 UTC (Thu) by nelhage (subscriber, #59579) [Link]
Interesting. So the kernel could conceivably set up a segment so that libc could jump into a 64-bit compat shim before making syscalls.
The problem of libc having to know about all these random ioctl calls so that it can marshal their parameters between 32-bit and 64-bit mode still exists, though, and I don't see a good solution there.
The hazards of 32/64-bit compatibility Posted Sep 23, 2010 16:07 UTC (Thu) by avik (guest, #704) [Link]
This marshalling needs to exist anyway, the only question is whether in the kernel or userspace.
The hazards of 32/64-bit compatibility Posted Sep 23, 2010 17:03 UTC (Thu) by nelhage (subscriber, #59579) [Link]
Right, but the kernel has to know the layout and structure of all of these structs, anyways, since it has to extract the data to use it. So it's only a little more work, comparatively, to also have 32-bit parse code.
Whereas currently, libc doesn't have to know anything about ioctl formats, it just passes a pointer along. And so if you compile a new kernel module that has some random new ioctl()s, and install the corresponding user programs, everything works. But if libc has to do the marshaling, I also need to update my libc, which is much harder.
The hazards of 32/64-bit compatibility Posted Sep 23, 2010 17:35 UTC (Thu) by avik (guest, #704) [Link]
The trick is that the kernel provides the compatibility library, not libc.
(Userspace vs kernel) != (libc vs kernel)
|
|||||||||||||