[Nix-dev] end-of-life kernels

[Mathijs Kwik]

Lluís Batlle i Rossell <viric at viric.name> writes:

> On Mon, Nov 19, 2012 at 02:26:00PM +0100, Mathijs Kwik wrote:
>> Marco Maggesi <maggesi at math.unifi.it> writes:
>> 
>> > For the record, I still use 2.6.35 which is the newest kernel
>> > supporting BLCR presently available in NixoOS (BLCR needs kernels <=
>> > 2.6.38).
>> > By the way, for what I can say, this makes NixOS the only distribution
>> > which currently supports easily BLCR (just add two lines in
>> > configuration.nix).
>> > Seems that the development of BLCR has been resumed recently, but it
>> > still difficult to predict when there will be a new version that
>> > supports 3.x.y kernels.
>> 
>> We will keep 2.6.35 for now and it will become the only 2.6.x version.
>> Mainly because our current default kernel-headers version is 2.6.35 as
>> well. So in the short term, you're fine.
>> 
>> After next stdenv-upgrades-merge however, it seems 3.5.x will be chosen for the
>> headers, which might cause problems for older kernels.
>> Also, I would like to stabilize on long-term-supported kernels, which
>> means 2.6.32 or 2.6.34 in the 2.6.x range.
>> 
>> To combat the headers-problem, we can add a headers-compat/headers-2.6
>> package and have the system use those if the chosen kernel is lower than
>> our default (3.4 or 3.6 probably). This will cause rebuilds for almost
>> every other package, and probably hydra will not produce binaries for
>> systems that want to stay on 2.6, so it will take some more
>> building-from-source, but at least it keeps the possibility
>> to run older kernels open. I think that's a good trade-off.
>
> As for glibc, the glibc has to be told the minimum kernel version to build for.
> It will use not all syscalls available in the headers, but only those which
> match the 'configure' argument requirement.
>
> But I imagine Eelco wants glibc to be built for 3.5 kernels or above.

As 3.5 is dead, we should probably choose 3.4 or 3.6.

>
> In trunk we have glibc using an absurdly low kernel, and I think it ends up not
> having 'fstatat' making proper direct syscalls or something like that.

Upgrading this to a recent 3.4+ level sounds like a good idea.

Keeping an additional low/compat target around (headers + glibc minimum for
2.6.32) sounds like a good thing too, with the consequence that if you
want to use it, you need to compile a lot from source. Sounds like a
good trade-off. I suspect most uses for these lower kernel versions to
be related to specialized hardware or virtual machine targets, probably
not needing big X11 / desktop stuff, so it's not too bad.



>
> Regards,
> Lluís.
>
>> > 2012/11/19 Eelco Dolstra <eelco.dolstra at logicblox.com>:
>> >> Hi,
>> >>
>> >> On 18/11/12 20:58, Mathijs Kwik wrote:
>> >>
>> >>> Indeed I didn't think about 2.6.35 being our current headers, so
>> >>> indeed we should keep 2.6.35 until stdenv-upgrades.
>> >>
>> >> FWIW, the stdenv branch already uses Linux 3.5.x for the kernel headers.
>> >>
>> >> --
>> >> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
>> >> _______________________________________________
>> >> nix-dev mailing list
>> >> nix-dev at lists.science.uu.nl
>> >> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> > _______________________________________________
>> > nix-dev mailing list
>> > nix-dev at lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev