On 31 January 2012 15:01, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 31 Jan 2012, Zach Pfeffer wrote:
On 31 January 2012 11:19, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 31 Jan 2012, Zach Pfeffer wrote:
They love our builds, but they'd really like it if they could get stock AOSP builds for their boards on stable kernels that they can work with using fastboot that have been CI tested and QA'd.
I'm not advocating for the wholesale destruction of our current way of life, tip kernels, tip toolchains, linaro-android-media-create, but I would like to move in a direction that gives our users what they want.
And by the time you do that i.e. stable kernel and so on, then those customers will come back asking for this and that new cool feature available in the latest upstream kernel and ask you to backport it to your stable kernel.
Nico, you bring up a good point. Consolidating and upstreaming core ARM features that exist across each architecture is our main job.
The customer ask remains the same though. If we deliver a platform with a set of features, customers don't want any of those features to break when we give them an upgrade.
You just can't have it both ways. If you focus on a stable platform then you cannot have the latest features. If you develop new features, it obviously can't be stable. But whatever you do, customers will always ask for both in a single package.
I think it is a matter of clearly defining what we do, and also what we don't (and shouldn't) do. Expectations about Linaro cannot be the same as for Ubuntu/Canonical or Android/Google.
That is true., but lets talk nuts and bolts.
What I think would be good for Linaro to do, is to list the features of each board it wants to support without regressions and define a set of tests against those features. As we improve things, we ensure that the core feature set doesn't break. We have the test cases, so we know exactly what "break" means. This is fairly doable given that the kernel is conservative when accepting new API changes. Most of the features on our approved list are going to be drivers: SD card support, USB, ADB (for Android), etc... The only real big thing that I know of that may cause issues in this outer code ring is pinmux refactoring.
Then you've got features that touch the middle of the kernel, where changes to APIs are even less frequent. Here, multimedia acceleration and the other "stuff that must move large blocks of memory around" lives. These features are important to enable, because the targets are not very useful with out them, these have also been our major pain points. This will get better though as a new memory allocation architecture come in that meets users needs better. Given UMM , in a year most device manufactures will start to move their camera and audio drivers over to this.
Then we get to the worst offenders, graphics drivers. These tend to do very interesting things with VM tables against alloc_bootmem regions. UMM probably won't get used here since it won't give vendors the SoC specific, low-level per-page bit twiddling APIs that they need to eke out the last drop of graphics performance. These are definitely a problem, but if there's anywhere we should be confronting issues it would be right here since most of our members feel pain here the most.
The pain points we feel are the exact pain points we've been established to correct, but to correct them we still need a fairly useful and stable platform for people to work from. If we do plan on breaking something that something should be discussed and broadcast out before it breaks so people can prepare contingency plans.
At the end of the day, a platform with Ethernet, USB, Graphics, SD card support, and the other basic peripherals that enable kernel and userspace developers to work through each of these issues and that has been tested against a set of known tests would give the users of these platforms confidence in them, allowing them focus on improving the general ARM support in the kernel.
Nicolas