* Arnd Bergmann: > On Tue, Oct 1, 2019 at 5:38 PM Jens Axboe <axboe@xxxxxxxxx> 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-) Thanks, Florian
