On Wed, Jan 10, 2018 at 3:59 PM, Christoph Hellwig <hch@xxxxxx> wrote:
> On Wed, Jan 10, 2018 at 12:03:24PM +0100, Arnd Bergmann wrote:
>> I'd suggest passing a variant of timespec with two 64-bit members.
>> Deepa has posted patches for this structure in the past and was planning
>> to do a new version (with minor changes from review) soon, but we
>> can just well use it in your patch if that gets merged first.
>>
>> If we merge io_pgetevents quickly (before the bulk of the y2038 syscall
>> conversion), I'd say we should use
>>
>> struct __kernel_timespec64 {
>> __s64 tv_sec;
>> __s64 tv_nsec;
>> };
>>
>> The tv_nsec type is unfortunately much trickier than it should be:
>> C99 requires it to be 'long', so user space needs to define the 64-bit
>> 'struct timespec' with internal padding in the right places depending
>> on endianess, and the kernel has to be careful about either zeroing
>> the upper half or checking it for being zeroed by user space depending
>> on whether we come from a 32-bit or 64-bit task, but I'm fairly sure
>> we have that part worked out by now.
>
> Eww. Being the ginea pig is never good, and in this the fact that
> the aio syscalls aren't in glibc is just going to make things worse
> in chances of diverging from the future 'standard'.
>
> I'm tempted to say I'd rather deal with the new 64-bit time_t version
> later, especially as that should only affect 32-bit ports.
Ok, fair enough. Given that the old version gets obsoleted by this
one, it shouldn't get much uglier than it already is here when you
start out with a regular timespec. We just need to be aware of possible
clashes when we get the patches merged at the same time.
Arnd
