stable status

Gilles Espinasse g.esp at free.fr
Wed Sep 26 08:51:28 PDT 2007


Selon Robert Baker <bobb at netslyder.net>:

...
>
> Historically as this conversation has been brought up there is
> undoubtedly someone who asks why not 2.6? citing everyone else who
> builds their stable products on that kernel. I would agree to some
> extent that there is plenty of precedent for using the more current
> kernel revisions in a stable manner. Most problematic portions of the
> kernel tend to be marked clearly as experimental, and can simply be
> avoided. It is also worth mentioning nearly everyone who uses 2.6 in
> their stable products is using heavily patched versions of the kernel
> not vanilla versions. For that and several other reasons including 2.6
> would increase the need for a maintainer, but it would assuage some of
> the sentiment that HLFS stable would be behind the times.
>
There is some 2.6 version that have a stable branch still maintained even after
a long time.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=summary

That should be easier to maintain than using vanilla kernel with lot of changes
at each release. That even should be easier to maintain than 2.4.
2.4 branch become every day harder to maintain because new hardware may/will not
work.
As a simple example, take a simple e100 NIC driver.
e100 from 2.4 kernel does not support recent intel chipset (for example Intel
chipset 845 ).
With e100 driver from sourceforge, 3.5.17 does not work on 2.4 at all(at least
with IPCop toolchain environnement), 3.5.14 work but not with all NIC supported
by 2.4 kernel driver.
As code from both drivers is significantly different and it is not trivial to
make one of the driver better, I will end shipping both drivers because that's
the easiest way to proceed.

I don't think 2.4 kernel has a brilliant futur, even code base could be very
stable with old know hardware.

Gilles




More information about the hlfs-dev mailing list