Hi Adhemerval,

> On 08/10/2020 04:57, Lukasz Majewski wrote:
> > Hi Adhemerval,
> >   
> >> On 07/10/2020 11:25, Adhemerval Zanella wrote:  
> >>>
> >>>
> >>> On 07/10/2020 09:52, Adhemerval Zanella wrote:    
> >>>>
> >>>>
> >>>> On 06/10/2020 06:48, Lukasz Majewski wrote:    
> >>>>> Hi Adhemerval,
> >>>>>    
> >>>>>> A new struct __stat{64}_t64 type is added with the required
> >>>>>> __timespec64 time definition.  Both non-LFS and LFS support
> >>>>>> were done with an extra __NR_statx call plus a conversion to
> >>>>>> the new __stat{64}_t64 type.  The statx call is done only for
> >>>>>> architectures with support for 32-bit time_t ABI.
> >>>>>>
> >>>>>> Internally some extra routines to copy from/to struct stat{64}
> >>>>>> to struct __stat{64} used on multiple implementations (stat,
> >>>>>> fstat, lstat, and fstatat) are added on a extra file
> >>>>>> (stat_t64_cp.c).  Aslo some extra routines to copy from statx
> >>>>>> to __stat{64} is added on statx_cp.c.
> >>>>>>
> >>>>>> Checked with a build for all affected ABIs. I also checked on
> >>>>>> x86_64, i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and
> >>>>>> s390x.    
> >>>>>
> >>>>> When do you plan to pull this patch set to -master?
> >>>>> Those patches have been available for review on the mailing list
> >>>>> for more than two months now.    
> >>>>
> >>>> Hi Lukasz, thanks to remind me. I will rebase against master and
> >>>> run some regressions tests against some platforms and push it.
> >>>>    
> >>>
> >>> One required change with the rebase is adapt the riscv32 ABI to
> >>> exclude the __{f,l}xstat{at} symbol and replace with proper
> >>> {f,l}stat ones. It is possible because the new ABI was added on
> >>> current development branch, however one minor inconvenient is the
> >>> toolchain need to be rebuild with a updated glibc branch to avoid
> >>> linking failures with libstd++ (which uses __{f,l}xstat{at}).
> >>>     
> >>
> >> Ok, I have ran the testsuite on x86_64, x32, i686, aarch64, armhf,
> >> powerpc, powerpc64, powerpc64le, sparc64, sparcv9, s390x, and s390
> >> without regression. I will just finish the testing on mips, mips64,
> >> and alpha since they require some specific implementations.
> >>  
> > 
> > That would be a huge step forward.
> > 
> > According to list in the following commit message:
> > https://github.com/lmajewski/y2038_glibc/commit/73215359e184d96b415e87b585a4396b5bd0936c
> >  
> 
> The mips testing caught an issue on where the "linux: Disentangle 
> fstatat from fxstatat" patch uses INTERNAL_SYSCALL_CALL where
> it should use INLINE_SYSCALL_CALL (which sets the errno).  I have
> fixed and this only affects mips, so my testing should cover all
> the affects architectures (I got access to a ia64 machine again
> and I will run a regression test once I commit this to master).

Ok. Does it mean that we can expect those patches being pull to -master
soon?

> 
> > 
> > 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 :-)

> 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 send 1. 2. 3., since they are the easiest one to review.

Ok. Thanks :-)

> 
> [1]
> https://sourceware.org/pipermail/libc-alpha/2020-September/117484.html
> [2]
> https://sourceware.org/pipermail/libc-alpha/2020-September/117485.html
> [3]
> https://sourceware.org/pipermail/libc-alpha/2020-September/117486.html
> [4]
> https://sourceware.org/pipermail/libc-alpha/2020-August/116850.html
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de