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] |
Hi Arnd > On Thu, Jun 27, 2019 at 12:55 AM Lukasz Majewski <lukma@denx.de> > wrote: > > > 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? > > Yes. [ Even better would be a compile-time option to just leave out > the time32 support from glibc entirely, but as I understand that will > not be possible until most users have moved over to time64, > and users can't wait for that to do validation on products shipping > now. ] > > Mostly this means to just not put in code to support a case that > nobody cares about (running time32 applications on pure time64 > systems), so I would not expect this to cause extra effort in > development, just a little care with the implementation. > > > > > > > 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'm still not following. Which of steps listed below would that > > correspond to? I guess the last one, right? > > > > > > > - 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). > > I still don't see how that would break anything: if applications > are all built with 64-bit time_t, they would not call into the old > __clock_settime() function, which is then only kept around > for compatibility with old binaries and would still operate on > 32-bit time_t and use __NR_clock_settime. > > Arnd After the discussion I do believe that it would be correct to change the proposed patch [1] '__clock_settime' to: #if __TIMESIZE != 64 int __clock_settime (clockid_t clock_id, const struct timespec *tp) { /* For archs with WORDSIZE==32, which do not support clock_settime64 the clock_settime supporting 32 bit time ABI will be used */ return INLINE_SYSCALL_CALL (clock_settime, clock_id, tp); } #endif The "__clock_settime64()" part could be left untouched. Note: [1] - https://patchwork.ozlabs.org/patch/1107235/ 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:
pgpyNarJcaaUh.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] |