Hi Arnd,

> On Thu, Jun 27, 2019 at 5:23 PM Lukasz Majewski <lukma@denx.de> wrote:
> 
> >
> > I think that it is not necessary as the patch [1] has following
> > code:  
> 
> > #if __TIMESIZE == 64
> > # define __clock_settime64 __clock_settime
> > #else
> > extern int __clock_settime64 (clockid_t clock_id,
> >                               const struct __timespec64 *tp);
> > libc_hidden_proto (__clock_settime64)
> > #endif
> >
> > So for archs supporting 64 bit time syscalls (WORDSIZE==64 &&
> > WORDSIZE_SYSCALLS==64) we have the #define and the
> > weak_alias (__clock_settime, clock_settime) does the job.  
> 
> Ok, so you redirect both __clock_settime64 to __clock_settime
> and __NR_settime64 to __NR_settime, in order to get back to the
> same definition that you have today on 64-bit.
> 
> Sorry for taking so long to understand that.

Not only you had a hard time to understand it.

The approach presented in this patch steams from following guidelines:

https://www.gnu.org/software/libc/manual/html_mono/libc.html
"D.2.1 64-bit time symbol handling in the GNU C Library"


> 
> > If you are interested, please look into patch [2], which is a
> > proposition of using clock_settime as a part of Y2038 safe system.
> > This code corresponds to v3 of adding clock_settime syscall support,
> > which is a bit outdated as now we discuss v5. It gives a rough idea
> > though.  
> 
> Yes, that part looked fine to me from the beginning.

Ok. Good :-)

> 
>       Arnd




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