On 08.03.21 15:01, Philippe Gerum wrote:
>
> Jan Kiszka <jan.kis...@siemens.com> writes:
>
>> On 22.02.21 10:08, Philippe Gerum via Xenomai wrote:
>>>
>>> florian.bezd...@siemens.com <florian.bezd...@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 <a...@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
>
Ah, that is worth to remember!
Thanks,
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
