On 22.02.21 10:08, Philippe Gerum via Xenomai wrote: > > [email protected] <[email protected]> writes: > >> On Sun, 2021-02-21 at 16:27 +0100, Philippe Gerum via Xenomai wrote: >>> chensong via Xenomai <[email protected]> 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 <[email protected]> > > 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 was indeed v5.5-rc1 (seen via gitk, still looking for a handy git command line to explore that). Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
