| |||||||||||||
The hazards of 32/64-bit compatibilityThe hazards of 32/64-bit compatibilityPosted Sep 23, 2010 16:07 UTC (Thu) by avik (guest, #704)In reply to: The hazards of 32/64-bit compatibility by nelhage Parent article: The hazards of 32/64-bit compatibility
This marshalling needs to exist anyway, the only question is whether in the kernel or userspace.
(Log in to post comments)
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)
|
|||||||||||||