This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation


Hi Arnd,

> On Wed, Jun 26, 2019 at 5:03 PM Lukasz Majewski <lukma@denx.de> wrote:
> > > On Wed, Jun 26, 2019 at 11:07 AM Lukasz Majewski <lukma@denx.de>
> > > wrote:  
> > > > > On Tue, Jun 25, 2019 at 5:51 PM Lukasz Majewski
> > > > > <lukma@denx.de>  
> > > >
> > > > Shouldn't those syscalls be kept until the minimal supported
> > > > glibc kernel version is 5.1?  
> > >
> > > We will probably keep them as an option in the kernel until 2038,
> > > but leave it to the distro or embedded system design to turn them
> > > on or off.  
> >
> > Isn't this the ABI break on demand ?  
> 
> It's removing an unused ABI in order to ensure that nothing uses it.
> The policy is to never break things that users rely on, so you should
> only disable the system calls if you control all of user space and
> want to ensure that whatever works now doesn't break in the future.

In other words use glibc to help with validation of the system by
disabling (by kernel option) the time32 syscalls and check what happens?

> 
> > > The "#ifdef __NR_clock_settime" is always true when __TIMESIZE !=
> > > 64, so that could be simplified to the version I suggested.  
> >
> > For following setup: WORDSIZE=32, TIMESIZE=32 and kernel with
> > __NR_clock_settime returning -ENOSYS (disabled by embedded system
> > designer in the kernel), but supporting __NR_clock_settime64 (for
> > example 32 bit ARM):
> >
> > The policy question - shall the user space binary after calling
> > clock_settime:
> >
> > 1. Receive -ENOSYS as the __NR_clock_settime was used to fulfill the
> > request
> >
> > or
> >
> > 2. Receive 0 (operation succeed) as the available
> > __NR_clock_settime64 has been used to perform the requested
> > operation.
> >
> >
> > For the proposed patch (clock_settime) - the option 2 is now
> > performed.  
> 
> I would prefer to fail as early as possible, maybe even a failure
> from the ld.so when loading a binary that links against
> clock_settime() on a kernel that doesn't have the system call. That's
> probably too hard to implement, so abort(), or return -ENOSYS.

I see your point. Let's wait for other glibc developers opinion.

> 
> Definitely don't return success, that would defeat the purpose of
> disabling the syscall in the kernel, and just lead to silent incorrect
> data.
> 
> > > > However, there is the problem that in some point in time the
> > > > glibc will switch to 64 bit __TIMESIZE only (probably when
> > > > minimal kernel version for glibc would be grater than 5.1) and
> > > > all __clock_settime syscalls would be served with
> > > > __clock_settime64 (as 64 bit time support is always in place).
> > > >
> > > > After this switch the "unconverted" program will setup wrong
> > > > time.  
> > >
> > > I don't understand. What does it mean to switch to __TIMESIZE=64?
> > > Would that not break all existing binaries regardless of the
> > > implementation?  
> >
> > __TIMESIZE represents the size of time_t (the glibc internal time
> > representation). This change would be probably performed in the
> > future after the _TIME_BITS==64 is defined by default.  
> 
> I'm still not following. Which of steps listed below would that
> correspond to? I guess the last one, right?
> 
> > > Between adding the time64 system calls (now) and removing
> > > the time32 system calls (in y2038), there are a couple of
> > > intermediate steps that can be years apart, or all happen
> > > at the same time:
> > >
> > > - drop support for building with pre-5.1 kernel headers
> > > - stop running on pre-5.1 kernels
        ^^^ __ASSUME_TIME32_SYSCALLS flag which will be always true then

> > > - change the default for newly compiled code to time64
        ^^^ The _TIME_BITS==64 set by default (in glibc) for all
        compiled programs


> > > - drop support for building with time32  
        ^^^ TIMESIZE == 64 (no support for time32)

(But this need ACK from e.g. Joseph if I understood it correctly).

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

Attachment: pgpFDVNx3n5S4.pgp
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]