I am in the progress of updating the toolchain and thought it time to review
what our minimum required kernel version is for glibc.
For those that do not know, assuming a newer kernel allows glibc to have less
workarounds compiled in. So it may be advantagous to have a more recent version
as the minimum required. This comes at the obvious cost of not having support
for older kernels so a tradeoff is needed... When we discussed this 18 months
ago, it was decided 2.6.18 was appropraite then, but much has changed since.
I am going to suggest that we follow the oldest longterm support kernel. That
would now be the 2.6.27.x series, which has been around for over two years.
That might be being overly bold, so feel free to point out how much such an
update would break... and suggest an alternative minimum.
The workarounds obviously make maintainence a little more difficult, but is
there a performance hit too? Could a glibc and glibc-legacy/glibc-compat type of
thing be a viable solution? Then the question would be what kernel defines the
line between the two glibc packages (probably -lts would be good).
12-12-2010, 11:46 AM
glibc and minimum kernel version
On Sun, Dec 12, 2010 at 6:38 AM, Stéphane Gaudreault
> I think that udev >= 145-1 requires a minimum kernel version of 184.108.40.206,
> so building glibc for anything older may not make sense.
udev >= 147 requires a minimum kernel version of 2.6.27.