[Ksummit-discuss] [Stable kernel] feature backporting collaboration

[Alex Shi]

On 09/05/2016 05:28 PM, Laurent Pinchart wrote:
>>> Same as I said before, the risk LSK introduces, IMO, is much greater than
>>> > > rebasing and out-of-tree driver stack.

During the 3 years LSK work, I did get few bug report on LSK by users.
But they are some track bugs in common LTS. None of them in backporting
part.

>> > 
>> > I'm afraid you're very much mistaken if you believe that people are only
>> > working on leaf drivers, or that nothing we do upstream has a meaningful
>> > impact at the system level.
> To provide a real-life example, we recently ran into a scheduler issue in a 
> project I'm working on. The device is a phone running a Qualcomm kernel, and 
> the scheduler is so hacked by the vendor to cover the phone use cases that 
> creating a spinning high priority SCHED_FIFO thread in userspace kills the 
> system instantly. That's the kind of crap vendors tend to ship, and moving to 
> a newer kernel version pretty much means they have no revalidate all the 
> scheduler-related use cases (and add more awful hacks to "fix issues 
> introduced in mainline").

I am not a fun of some scheduler solution. But focus on this can not
explain why many distributions are using 'old' stable kernel. Looking
into product world, could you find some real product are using
'upstream' kernel?

'upstream first' is good for feature development, but isn't good for
product. Many product guys talked to me that the non-upstream porting
didn't cost much and not the reason to pin on some stable kernel. All of
them said that testing and stability was the most cost part. Not only
the regular test case, benchmarks, but also the long time using for some
trick/corner case bugs in whole system.

I doubt the 'keep rebasing on upstream' guys have been really worked on
product?