On Sun, 18 May 2014, H. Peter Anvin wrote: > This potentially requires the kernel to maintain three separate ABIs if > there is a legacy 32-bit ABI, which is quite frankly idiotic. You seem Three ABIs seems reasonable enough to me where appropriate. > to be thinking of POSIX as something handed down by gods, which it > isn't... quite frankly they did something stupid here and should fix > their own mess. In the real world it's useful to support lots of different standard versions, not just some hypothetical future version (I see no evidence of anyone thinking there is a POSIX defect actually having raised the issue with the Austin Group to see if anyone there agrees a change would be useful). We've only just removed support for _BSD_SOURCE / _SVID_SOURCE as defined API levels from glibc; I'd guess it will be about 20 years before removing support for POSIX.1-2008/2013 is appropriate (even if the next major edition relaxes this requirement). > As far as glibc is concerned, this would require glibc to intercept each > ioctl, which is completely infeasible... struct timespec/timeval is > embedded far too deep everywhere. Well, maybe the subset of applications passing timespec to ioctls should carry the cost of converting from the userspace timespec to the kernel timespec, rather than POSIX applications carrying the cost of unnecessary incompatibility. (But an enumeration of the relevant ioctls is needed anyway simply to provide new versions of them all for 64-bit time_t.) -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
