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


* Lukasz Majewski:

> Hi Arnd,
>
>> 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 ?

Yes, it is.  It happened with vsyscall, too.

Stuff like that is only feasible if you expect that a dynamically linked
libc is the ultimate ABI boundary for applications.  I don't think
that's realistic or actually intended, especially for things like
futexes.

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

In my opinion, an existing 32-bit architecture which does not provide
the clock_settime system call (that it has provided before) is just
broken, and will be so at least until 2038.

We can add the fallback code in glibc, but that will only give people
the wrong idea that they can disable the 32-bit system calls.  It's just
not true.

Thanks,
Florian


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