Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

Joseph S. Myers
2014-05-18T18:18:27Z

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@codesourcery.com