On 09/10/2020 12:39, Lukasz Majewski wrote:
> 
> Ok. Does it mean that we can expect those patches being pull to -master
> soon?
> 

Yes, I just push it upstream.

>>
>>>
>>> Then I will send an RFC for enabling support for 64 bit time on
>>> eligible architectures.  
>>
>> There still some missing implementations I have on my local tree:
>>
>>  1. wait3: it is a straightforward fix since it just calls
>> __wait4_time64. 
> 
> Ok.
> 
>> 2. ftime: we need to move it to a compatibility
>> symbol, so there will be no need to add a time64 variant to support
>> the deprecated symbol.
> 
> IIRC, such deprecation patch for ftime was already pulled to master:
> 
> SHA1: 2b5fea833bcd0f651579afd16ed7842770ecbae1
> "Consolidate and deprecate ftime"
> 
> From the commit description - it shall be removed by Y2038 :-)

This patch just make the prototype deprecated, it is still exported on
all architecture and built for newer ABIs (riscv32 for instance).
The idea of my patch is move it to a compat symbol only, meaning that
it won't be available to binaries build against glibc 2.33 and new
ABIs won't provide it (which will be the case for riscv32). 

> 
>> 3. futimesat: we need to remove the
>> implementation on generic folder and handle UTIME_NOW and UTIME_OMIT
>> correctly.
> 
> Ok.
> 
>> 4. recvvmsg/recvmsg: we need to handle ancillary data. I
>> recently send patch that tries to handle it [1] [2] [3]. It is more
>> in a RFC and I don't think it is strictly necessary.
> 
> Ok.
> 
>>  5. utmp/utmpx/lastlog: I also sent a fix to handle the 64-bit support
>>     on this [4]
> 
> I saw conversion patches in your y2038 tree (sourceware/azanella/y2038)
> on top of the stat conversion work, so I guess that it will be next in
> the queue.

I will rebase my y2038 changes and update my tree.