Re: Requiring Linux 3.2, again

[Carlos O'Donell <carlos at redhat dot com>]

On 05/04/2017 07:47 AM, Joseph Myers wrote:
> On Thu, 4 May 2017, Carlos O'Donell wrote:
> 
>> At a high level I worry about container technology (regardless of the
>> choice of framework around namespaces) and the pressure we apply to users
>> by moving glibc to require a newer kernel.
>>
>> Every time we move glibc to require a newer linux kernel that creates an
>> inflection point where users have to upgrade their container host to run
>> the newer distribution containers.
> 
> Even without glibc requiring a newer kernel, it's entirely plausible that 
> some userspace software on new distributions will in fact be relying on 
> new kernel features and so fail to work on containers with old host 
> kernels unless those features have been backported.  E.g., if it uses 
> getrandom (Linux 3.17) and doesn't have a runtime fallback for it being 
> unavailable (only maybe e.g. a configure-time fallback for being linked 
> with old glibc without the function).
 
Yes, but in that case it's just *one* application which fails at runtime,
and the application author is considered at fault.

If glibc causes the container to even boot before allowing applications to
run, then we get blamed, and the politics of the situation are different.

What stops us from simply allowing individual interfaces to fail according
to the results of the syscalls they make? Or in some cases just calling
abort if the syscall is critical for operation of glibc? This would move
glibc out of the path of blame, and make it the fault of the developer?

Assume your application only used memset. With a bumped up minimum kernel
version we would no longer run that application on an older host. Shouldn't
we just allow it to run?

Now that the minimum kernel version is moving forward smoothly and we all
like the cleanups. Perhaps it's time to question the "FATAL: too old" warning
and remove it?

-- 
Cheers,
Carlos.