bug#63850: cp fails for files > 2 GB if copy offload is unsupported

[Arsen Arsenović]

Paul Eggert <eggert@cs.ucla.edu> writes:

> That's not surprising, as this sort of problem arises only when building for a
> newer platform yields a package that will run incorrectly on an older
> platform. Problems like these are relatively rare if the only such mismatch is
> the Linux kernel version, because current glibc explicitly supports building
> for Linux kernel>=3.2, even when glibc is built on newer kernels, these days
> nobody doing this sort of thing cares about kernels older than 3.2, and most
> packages rely entirely on glibc to access the kernel. There are exceptional
> packages, though, and you may run into problems with those exceptions.
>
> If users build for newer platforms and it usually works on older platforms,
> that's great! But you might want to document that it might not work. Because 
> it
> might not.

In this instance, we have a configure-time test that makes a false
assumption (namely, that linux-headers version matches the linux
version), preventing a very valid runtime test from being emitted.  The
cost for enabling this check is removing a dozen or so lines of code in
copy-file-range.m4 (and the subsequent addition of a few instructions
and a single syscall that is executed once).

It is entirely reasonable to expect that a user will roll back a kernel
update, as there are many reasons one might have to do so.

This is not quite comparable to downgrading libraries (which will,
reasonably, break as a result), because the kernel<->userspace boundary
is of very different nature to the library<->* boundary (namely, the
former is far more 'loose', in the sense that failure to implement
something manifests as a runtime failure rather than a build-time, or
even rtld-time failure).  It is no coincidence that glibc explicitly
supports kernels older than the linux-headers it's being built with.

I'd understand not wanting to support this use-case in the cases where
doing so is difficult, but here, it's more difficult to not support this
use-case than to support it.

Please reconsider dropping the configure-time version check.

Thanks in advance, have a lovely day.
-- 
Arsen Arsenović

signature.asc
Description: PGP signature