Re: [Ksummit-discuss] [LTSI-dev] [Stable kernel] feature backporting collaboration

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

On Tue, Sep 13, 2016 at 03:12:49PM +0200, Greg KH wrote:

> People say "look, we are using an LTS kernel in our product, all must be
> good!" but if they don't update it, it's broken and insecure, and really
> no better than if they were using 3.10.0 in a way.

Do they actually say that?  I can't recall that being a selling point
for any of the devices I've bought...  For Android Google are now
talking about delivering security updates and advertising their
frequency a lot more but I don't recall LTS being part of that sell.

> But if we didn't provide an LTS, would companies constantly update their
> kernels to newer releases to keep up with the security and bugfixes?
> That goes against everything those managers/PMs have ever been used to
> in the past, yet it's actually the best thing they could do.  It's a
> long road of education and doing work on their part to get test
> frameworks set up to be able to qualify "larger" upgrades.  It also
> requires that their chip vendor not add 1.5 million lines of code to
> their kernel, rewrite the scheduler, and duplicate all existing drivers
> with a "-2" suffix.

I'm not sure I'd go so far as saying everyone should be tracking
mainline in production - the enteprise distros and their users haven't
been persuaded yet either.  It's definitely a useful goal to get people
doing that though, especially for longer lived devices it just makes so
much more sense.  In the Android world we already see some vendors
shipping an entirely new userspace version which ought to be at least as
risky as a new kernel, though there's also going to be rather more
direct user demand pushing it.

> Ok, this is rambling, and something I've been mulling over for a while
> now.  I'm working with some people at some of the chip companies to see
> about how we can do this better, hopefully the work of education,
> testing, and other assurances can help everyone out in the end, and
> start to resolve these issues, but it's going to be slow going.

The issues around deploying updates into the field are at least as much
if not more of an issue at the system integrator level and potentially
more directly marketable for them - are you talking to them as well?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]