Messages in this thread | | | Date | Mon, 16 Jan 2023 22:07:25 -0500 | From | "Theodore Ts'o" <> | Subject | Re: Reg the next LTS kernel (6.1?) |
| |
On Mon, Jan 16, 2023 at 01:16:33PM +0100, Michal Simek wrote: > > This is probably the best reason not to preannounce when the LTS > > release will be ahead of time --- because it can be abused by > > developers who try to get not-ready-for-prime-time features into what > > they think will be the LTS kernel, with the result that the last > > release of the year could be utterly unsitable for that perpose. > > None is saying that not-ready-for-prime-time feature is pushed. > In our case all code before upstream goes to soc vendor and it stays there > for quite a long time when developers have time to upstream it. > I can imagine that this can happen when you use upstream first solution > where the code is not fully tested on all configurations.
The problem is that sometimes code meant for a particular SOC could break other users. The most extreme versions of this was an SOC kernel that support in for big.little ARM CPU's that created generic kernel .c files that *would* *not* *compile* on x86. I've seen this personally, and it impacted the ability for me to implement ext4 encryption for Chrome and Android, in that it worked fine on the upstream kernel (because *I* develop my featuers upstream first), but broke when I had to adapt and make chagnes for the SOC kernel that had changs that had not been pushed upstream.
So if it hasn't been pushed to the upstream kernel, all of the testing in the world in the SOC kernels doesn't count. Push to upstream *first*, and *then* backport to the SOC kernel. Better yet, if all of your device drivers are developed upstream first, then you might not need that never to be sufficiently @#$?!@? SOC kernel...
> But our customers/users are making products based on code we developed for them. > That's why I am telling to developers to upstream code whenever it is ready > to be upstreamed but not everybody is following recommendations . And for > new SOCs we should be couple of months ahead for any customer that's why it > shouldn't really matter if that feature goes to one or another kernel.
If people don't listen to you, then they deserve all the pain that they get, and upstream should not be bending over backwards for them. And maybe we can try to get mobile device manufacturers to choose not to chose that SOC when making choices for their next generation flagship devices....
- Ted
| |