On 21 June 2013 19:21, Mark Brown broonie@linaro.org wrote:
On Fri, Jun 21, 2013 at 09:40:43AM +0800, Andy Green wrote:
On 21 June 2013 00:22, Mark Brown broonie@linaro.org wrote:
So, my previous job was all about shipping into smartphones so I'm more than familiar with the situation here - this is in no way specific to Linaro, it's a pressure felt by everyone shipping into the consumer electronics space. To me part of teaching people about the value of upstreaming is teaching them how that process interacts with and helps the process of stabalisation for release.
This kind of assumes the Landing Teams are in a position where people are interested in their "teachings". More often someone in higher management has realized that the LT can do them a lot of good, but on the ground that's not always understood. If the company in question has established fiefdoms, it can get difficult even reaching agreement on LT necessities like having a rebase tree (the otherwise excellent Felipe Balbi at a member gave me a nice lecture about his certainties we should use history trees, because the reasoning was outside his experience).
Of course, I'm not saying that this is a trivial thing to sell but that doesn't mean we shouldn't be pushing it. If it reall was trivially obvious probably everyone would be doing it already :)
Yes this gets pushed, and we demonstrate by doing it, which is highly effective against people saying it can't be done.
However this LKS kernel will definitely make tracking activity harder for us. The problem will be all the driver integration focus at the member will be at LKS kernel and not tracking. Since LKS has a direct line to product ship date, parallel driver integration at later tracking kernel they're not shipping will seem like a distraction. We could do the driver integration engineering work at tracking and backport to LKS, but this really is needlessly inefficient from product-focused observer POV.
If we don't do something about it for tracking, by default we end up with a single old tree that works well and no forward path for the code.
When LKS and HEAD are closely aligned, it's not going to be that difficult to follow LKS integration work on tracking. However when LKS and HEAD diverge significantly rebasing the LKS-aligned patch to HEAD each time may be a nasty job.
Perhaps if the LT tree based on LKS is kept by rebase, with the "squashed topic patches with history via tags" method, there's a way to port LKS-based driver patches initially to tracking, then squash interdiffs between the last ported tag and new tag on the LT LKS tree to the tracking tree patch for the same function. It would require care but then you only need to do the main uplevel porting once and there's a path to follow LKS-based changes.
Essentially everyone in the Android space will be working on v3.4 up until the release of Key Lime Pie. That's the stable kernel for Jelly Bean, that's what everyone works with. For ICS it was v3.0, though that's pretty much dead at this point for anything except support.
Not in "some" companies: it's still alive and getting new engineering work done on it, despite it being explained it's like giving birth to old men. For the people who think that's OK, I'm worrying the LTS kernel will allow them to argue for that approach.
Our current plan of record is to taper off new features after a year so hopefully there's at least some back pressure there.
Yes it'll stop clinging on to it forever anyway.
As far as device tree goes... it's not really solving a problem that people doing phones have. People will use it (and IME do use it) when
However the code we have seen from vendor suppliers for drivers is really nasty in many cases. It's quite normal to embed physical addresses and IRQs direct in the driver code, we even got one where they had put Samsung pre-generic gpio gpio api usage right in there (the driver is nothing Samsung specific). Even Mali has that kind of stuff piled in there. So even for phones DT will be very valuable (and I noticed yesterday, Chromebook kernels have DT attached to kernel binary). It is expensive running around dealing with and maintaining that.
Note however that the Chromebooks aren't fully supported with only DT yet - we still need to work out how to handle things like the WiFi reset. As far as the code quality thing goes my experience is that DT will just push around the quality issues, it won't stop them (as you'd expect really).
I agree with what you're saying they don't feel that yet and there's no DT backport pressure, it's because they are used to one kernel per product and wasting time running around the code meddling as a one-off, rather than one kernel per member and CONFIG_ARCH_MULTIPLATFORM / DT and do the work once.
That's not really it - the trick is to keep the active parts of the code in sync with each other to minimise redundant development and there's other ways of doing that than doing a single binary for multiple boards that people have already figured out. By the time you get to actually shipping most of the effort is on QA anyway which for thoroughness needs to be on a per system basis.
The QA certainly needs to be done individually on the final system. We'll see the impact (or not) as we go, but at least nothing about DT and ARCH_MULTIPLATFORM stops them having a single source tree and doing it the old way for as long as they like. But I expect we see reasons why one kernel binary will become highly interesting and eliminate a lot of work for people that embrace it.
He mentioned that the Andriodization patches are in LTS already... what I was initially talking about is how to make sure llct merged content is still there if we later switch our LT kernel to use LTS basis. So if he added a pending series about xyz subsystem to llct for 3.x, it's arguable to expect that the accepted series for xyz subsystem appear in some downstream version of LTS for 3.x, even if it was accepted after 3.x.
That's what we'll be going for for for anything which is included in LTS, though that won't be absolutely everything that is being done within Linaro.
Great.
As I said that's probably not your problem, it's something Andrey could take care of doing on top of your mainline-only core LTS branch, but there needs to be a discussion about if we even want that, or if content added at llct just stops at llct and your mainline-only core LTS branch is all there is.
I suspect the backports will be too much effort there for anything with non-trivial invasiveness and that people might want the support. From an encouraging people to upstream point of view it does also seem like we should have some barriers on the backports, to a certain extent what
Yes backports are not good things to encourage.
Generally though the llct idea is adding things before upstream because they're desirable even at the current version. So there should at least be a chance they each might be candidates for backport treatment in LKS.
-Andy