Re: Next LTS release

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Just chiming in based on my experience with old kernels.

On Wed, Jun 08, 2016 at 08:22:38AM -0700, Greg KH wrote:
> > >> The reason I'm asking is that my company plans to release an SDK
> > >> in Q4, and I was hoping to bundle a recent kernel.
> > > 
> > > Nothing preventing you from always just advancing your kernel to the
> > > latest LTS one when it comes out, right?
> > 
> > Some customers, once they have something working, they don't want
> > to change anything. If I release a v4.4-based SDK, and then such
> > a customer comes along, I'll be stuck having to support v4.4 until
> > my beard is grey.
> > (I was told we are still expected to support several 2.6 kernels.)
> 
> You can tell them that they are running insecure kernels that are
> trivial to break into, and provide them with the latest kernel release
> to resolve that.

FWIW I just checked, and since we dropped 2.6.32.y 3 months ago, at least
2-3 null pointer dereferences affect it, that can be used either just to
crash the system, or even to gain privileges under certain conditions.

There is a good rule of thumb : if your kernel doesn't appear anymore
on https://www.kernel.org/category/releases.html, YOU'RE IN VERY SERIOUS
TROUBLE!

> > The platform code got merged in 4.5 and 4.6 but I'm still missing
> > several important (but non-essential) drivers. Thus 4.4 isn't really
> > helpful to me, I'd have to port everything.
> 
> Then pick 4.6 and support it and then give them 4.7, and 4.8, and so on.
> It's not hard, and everything will still work just fine, that's a
> guarantee we made a long time ago and it's worked.

And even to limit the number of upgrades, first jump from one version to
another until one is declared LTS and you can stick to it for as long as
it is supported. Customers will prefer to run on a well-known LTS version
than one you maintain yourself anyway, so they'll be willing to accept
these small update steps for a few versions at the beginning. And they'll
benefit from improvements.

> Some are supported longer than others because we have developers willing
> to do that support, for various different reasons (usually because it
> makes their day-job easier).  There's no real specific reason to justify
> any of the time lengths for them, sorry.

I personally take over maintenance of the kernels we ship with our
products, and we ensure to pick LTS kernels to save me from doing
useless work. In the past we used to have quite a number of backports,
and by catching up with more recent LTS versions we could get rid of a
lot of patches and simplify our job. It also means that I have less
extended LTS work to do, which is good considering that the difficulty
grows with time. I definitely think that most users who absolutely need
LTS kernels should proceed similarly, and that those who don't absolutely
need LTS should use a recent enough kernel that is still actively maintained.

I'd also like to mention something regarding very long time maintenance
for having worked on quite old kernels for some time (including 2.4).
There's a point where the quality starts to decrease again due to bugs
introduced in backports, just because the code is so much different that
it's hard to get a backport right. I can't say how long it takes for a
kernel to be screwed, but I definitely screwed 2.4 a few times, and would
have screwed 2.6.32 many times if some careful reviewers had not spotted
my mistakes in time. Reviewers will not participate forever to an antique
release, and there will even be a moment where they will make mistakes as
well. Just for this it's important to force customers to upgrade. Establish
a 3-4 years plan if that works for you, but you need to enforce a deadline.

Just my two cents,
Willy
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]