On 10/1/19 10:07 AM, Florian Weimer wrote:
- Arnd Bergmann:
On Tue, Oct 1, 2019 at 5:38 PM Jens Axboe axboe@kernel.dk wrote:
On 10/1/19 8:09 AM, Jens Axboe wrote:
On 9/30/19 2:20 PM, Arnd Bergmann wrote:
All system calls use struct __kernel_timespec instead of the old struct timespec, but this one was just added with the old-style ABI. Change it now to enforce the use of __kernel_timespec, avoiding ABI confusion and the need for compat handlers on 32-bit architectures.
Any user space caller will have to use __kernel_timespec now, but this is unambiguous and works for any C library regardless of the time_t definition. A nicer way to specify the timeout would have been a less ambiguous 64-bit nanosecond value, but I suppose it's too late now to change that as this would impact both 32-bit and 64-bit users.
Thanks for catching that, Arnd. Applied.
On second thought - since there appears to be no good 64-bit timespec available to userspace, the alternative here is including on in liburing.
What's wrong with using __kernel_timespec? Just the name? I suppose liburing could add a macro to give it a different name for its users.
Yes, mostly the name.
__ names are reserved for the C/C++ implementation (which does not include the kernel). __kernel_timespec looks like an internal kernel type to the uninitiated, not a UAPI type.
Once we have struct timespec64 in userspace, you also end up with copying stuff around or introducing aliasing violations.
I'm not saying those concerns are valid, but you asked what's wrong with it. 8-)
FWIW, I do agree, __kernel_timespec sounds like an internal type, not something apps should be using. timespec64 works a lot better for that. Oh well.