On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote: > On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On the other hand I've heard > > that various hardware vendors or parties closed to them are rather > > annoyed by their drivers beeing stuck in the android tree - but that > > can be easily solved by getting removing the suspend blockers (at least > > temporarily), cleaning up a few bits here and there and getting them in. > This continues to baffle me. If we (Google) are such a headache, why > not just route around us. The drivers we've written are GPLv2, the > source is out there for anyone who wants it, etc. The drivers other > people have written we have no control over at all. From my point of > view it'd be an annoyance if somebody took the code we wrote, modified > it heavily, and pushed it upstream, but fundamentally I can't stop > that from happening other than by pushing it upstream myself, first. AFAICT this is purely down to the fact that the vendors producing Android devices are using the kernel which is shipped with whatever release they are using so people doing drivers end up getting locked in to an older kernel with old APIs (independant of Android specifics) and don't have the resource to redo things for upstream. Suspend blockers are one more API update in there, but general kernel development creates far more. I was looking at this just today and one thing that it occurs to me might help is if when you guys rebase your work against upstream you were to tag the results - at the minute the only "release" Android kernels are those included in full stack releases so providing more hints that other kernel versions could be substituted in may help. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
