On Tue, 31 Jan 2012, Zach Pfeffer wrote:
> On 31 January 2012 15:01, Nicolas Pitre <nicolas.pi...@linaro.org> wrote:
> > 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.
Absolutely. This is why the Linaro CI loop is so important.
[...]
> 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.
I can't agree more. However there won't be any good solution here
without access to the source code for those graphics drivers. I don't
see any easy way out.
Nicolas
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
