What our customers want from Android

Zach Pfeffer zach.pfeffer at linaro.org
Wed Feb 1 03:17:21 UTC 2012


On 31 January 2012 15:01, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> On Tue, 31 Jan 2012, Zach Pfeffer wrote:
>
>> On 31 January 2012 11:19, Nicolas Pitre <nicolas.pitre at 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



-- 
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog



More information about the linaro-dev mailing list