Re: [PATCH 2/5] cobalt/kernel: y2038: convert struct timespec to timespec64

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 22.02.21 10:08, Philippe Gerum via Xenomai wrote:
>> 
>> florian.bezdeka@siemens.com <florian.bezdeka@siemens.com> writes:
>> 
>>> On Sun, 2021-02-21 at 16:27 +0100, Philippe Gerum via Xenomai wrote:
>>>> chensong via Xenomai <xenomai@xenomai.org> writes:
>>>>
>>>>>> +/*
>>>>>> + * Our representation of time at the kernel<->user interface boundary
>>>>>> + * at the moment, until we have fully transitioned to a y2038-safe
>>>>>> + * implementation in libcobalt.
>>>>>> + */
>>>>>> +struct __user_old_timespec {
>>>>>> +	long  tv_sec;
>>>>>> +	long  tv_nsec;
>>>>>> +};
>>>>>
>>>>> why not use old_timespec32, which is timespec32 representation defined
>>>>> in include/linux/time32?
>>>>>
>>>>
>>>> Using old_timespec32 in this context would mean that any time value
>>>> received from userland by the core should be restricted to 32bit time_t,
>>>> which is not what we want, at least for 64bit platforms:
>>>>
>>>> include/vdso/time32.h:
>>>>
>>>> struct old_timespec32 {
>>>> 	old_time32_t	tv_sec;
>>>> 	s32		tv_nsec;
>>>> };
>>>>
>>>> __user_old_timespec conveys the notion that we are generically talking
>>>> about "the old timespec type which has a y2038 problem"; this is not
>>>> specifically about the legacy timespec type on 32bit machines.
>>>>
>>>> Since v5.4-rc6, we do have __kernel_old_timespec though, which could
>>>> have been used instead of __user_old_timespec:
>>>
>>> According to my information (based on
>>> https://elixir.bootlin.com/linux/v5.5-rc1/A/ident/__kernel_old_timespec
>>> ) this is available since v5.5-rc1.
>>>
>> 
>> This disagrees with the git history then:
>> 
>> commit 94c467ddb273dc9a6a4fb09aef392c119b151edb
>> Author: Arnd Bergmann <arnd@arndb.de>
>> 
>>     y2038: add __kernel_old_timespec and __kernel_old_time_t
>> 
>> $ git describe 94c467ddb273dc9a6a4fb09aef392c119b151edb
>> v5.4-rc6-2-g94c467ddb273dc9
>> 
>
> This tells you *after* which tag it was applied, not when it was in and
> tagged there.

That's right. My mistake.

> That was indeed v5.5-rc1 (seen via gitk, still looking for
> a handy git command line to explore that).
>

$ git describe --contains

-- 
Philippe.