Re: Requiring Linux 3.2, again

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 4 May 2017, Carlos O'Donell wrote:

> > Based on the dates shown there, we might consider moving from a 3.2 
> > minimum to a 3.16 minimum for glibc 2.28 (Aug 2018) or 2.29 (Feb 2019).  
> > But actually it doesn't look like there's any difference between 3.2 and 
> > 3.16 for features glibc cares about on x86 / x86_64 (whereas there *are* 
> > cleanups possible by moving from 2.6.32 to 3.2), so there would be very 
> > little cost to keeping the version back on some architectures (while 
> > moving to require 3.16 on other architectures) if that makes sense at the 
> > time.  And of course if 3.10, say, is in fact still supported when 3.2 
> > ceases to be, that rather than 3.16 would be the version to consider.
> 
> I think I've outlined another argument in my downstream email. That the
> abort we issue for being on too old a kernel may be too catastropic here
> and that there might be a middle ground where such applications could work
> and we don't let them.

Empirically, userspace QEMU, told to fake a newer kernel version than is 
actually running on the host, works quite well for running e.g. GCC tests 
(though some libstdc++ threading tests fall over, since threading doesn't 
work very well with userspace QEMU).  I don't know to what extent it does 
any emulation of syscalls or just converts them to the corresponding host 
syscalls, but if it converts to (possibly missing) host syscalls that 
doesn't seem fatal for those tests.

(I have wondered how much of the glibc testsuite could usefully run in 
userspace QEMU (and thus whether build-many-glibcs.py could support a mode 
running a subset of execution tests on userspace QEMU for architectures 
with the right support, as something between just running compilation 
tests as at present, and running the complete testsuite which would 
require booting an actual OS on the desired architecture).)

-- 
Joseph S. Myers
joseph@codesourcery.com