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