On 31 January 2012 21:54, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Tue, 31 Jan 2012, Zach Pfeffer wrote:
On 31 January 2012 15:01, Nicolas Pitre nicolas.pitre@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.
I agree. I've been collecting input from a lot of people around the industry that I'm going to present during ELC at Binary Blobs Attack!! that's going to talk about this explicitly.
Nicolas