Re: [PATCH 05/20] lib/cobalt: Introduce wrappers_time64.c

On 20.02.26 15:46, Florian Bezdeka wrote:
> On Fri, 2026-02-20 at 15:36 +0100, Jan Kiszka wrote:
>> On 20.02.26 10:08, Florian Bezdeka wrote:
>>> All COBALT_IMPL_TIME64() services will be moved afterwards - step by
>>> step - into the newly introduced wrappers_time64.c. At the end that
>>> should allow us to compile libcobalt with time64_t support leaving
>>> the native time_t services in place.
>>>
>>> Currently, all native time_t services are replaced by the 64 bit
>>> variants. That is OK as long as applications are rebuild after
>>> libcobalt, but we try to remove this limitation now.
>>>
>>> Signed-off-by: Florian Bezdeka <[email protected]>
>>> ---
>>>  lib/cobalt/Makefile.am       | 3 ++-
>>>  lib/cobalt/wrappers_time64.c | 6 ++++++
>>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/cobalt/Makefile.am b/lib/cobalt/Makefile.am
>>> index f461e570ed42a0d5cbc43eabb373c3c9edd83bad..17e203f9015fe2bb5306609e4d51c62f3a725780 100644
>>> --- a/lib/cobalt/Makefile.am
>>> +++ b/lib/cobalt/Makefile.am
>>> @@ -43,7 +43,8 @@ libcobalt_la_SOURCES =		\
>>>  	timerfd.c		\
>>>  	trace.c			\
>>>  	umm.c			\
>>> -	wrappers.c
>>> +	wrappers.c		\
>>> +	wrappers_time64.c
>>
>>
>> So, a should we do a wrapper_off64 for mmap, or put both into the same
>> one? I don't have a good name for common one yet, though.
> 
> Both should be possible, I think, but testing has to prove that.
> 
>>
>>>  
>>>  libcobalt_la_CPPFLAGS =			\
>>>  	@XENO_COBALT_CFLAGS@		\
>>> diff --git a/lib/cobalt/wrappers_time64.c b/lib/cobalt/wrappers_time64.c
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..4c4e0db0650b49f46cbd6d9ecf7cd656bb04bbe4
>>> --- /dev/null
>>> +++ b/lib/cobalt/wrappers_time64.c
>>> @@ -0,0 +1,6 @@
>>> +/*
>>> + * Magic ahead:
>>> + * This file is compiled twice in case y2038/time64_t support is necessary
>>> + * and requested. The first time with time64_t and a second time with native
>>> + * time_t.
>>> + */
>>>
>>
>> Header, but still no copyright notices...
>>
> 
> Yes, I forgot the license headers / copyright notices because I was not
> sure if I should add SDPX headers or the full blown license text...
> 
> Any preferences?

When moving existing code, better keep things as they were. SPDX can be
added, but it should not replace old statements.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center