This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix Arm __ASSUME_COPY_FILE_RANGE (bug 23915) [committed]
On Mon, Nov 26, 2018 at 7:14 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 26/11/2018 14:46, Joseph Myers wrote:
> > On Mon, 26 Nov 2018, Florian Weimer wrote:
> >>> 2018-11-23 Joseph Myers <joseph@codesourcery.com>
> >
> > (I think kernel 4.4, when many socket syscalls can be assumed to be
> > available everywhere, will be the next point where there are significant
> > simplifications to be gained in glibc sources by increasing the global
> > minimum kernel version supported - many of those functions will be able to
> > move to just having a single entry in syscalls.list.)
> >
> On same discussion I also raised, from Florian's suggestion, about focal
> points relating to libc kernel iteration and Arnd Bergmann and Peter Anvin
> volunteered. I am ccing them so we can improve the syscall additions for
> new Linux releases.
>
> Arnd also said the idea is to have the new 64-bit time_t syscalls for all
> affected architectures when it is accepted upstream.
Regarding the minimum releases, I assume the y2038 work will require
a split of the minimum runtime kernel version and the minimum kernel
header version. I'd aim for 4.21 or 4.22 to be the first kernel version that
has workable kernel headers for all sytem calls and ioctls, on all
architectures, so this would likely become the minimum version for
building glibc again for a long time.
As the runtime minimum version, 4.4 sounds reasonable, this is also
the oldest longterm stable kernel we currently support aside from the
ancient 3.16 release used primarily by Debian Jessie (oldstable). This
will be three years old by the time glibc-2.29 gets released. The last
time the minimum kernel version was raised in glibc-2.24, the
linux-3.2 release was 4.5 years old, the final stable 3.2.x release
was this summer after 6.5 years.If you wanted to go by those numbers
alone (ignoring technical benefits of picking a particular release),
glibc could move to 3.16 minimum now, and change to 4.4 in summer
2020 when 3.16 is expected to end.
When we synchronize the system calls during the y2038 work
and require a new header version 4.22 or something like that,
this would also make a good minimum binary version some three
to six years later, and then allow removing many of the remaining
differences between architectures, we just need to make sure
we can of the unintended differences now and fix them.
Arnd