On Wed, May 26, 2010 at 3:54 PM, Florian Mickler <florian@xxxxxxxxxxx> wrote: > It really comes down to a policy decision by the distribution maker. > And I don't think kernel upstream should be the one to force one way or > the other. So merging this patch set will allow android to continue > their work _on mainline_ while everybody else can continue as before. > > All points about the impact on the kernel have already been raised. So > you should be happy there. > > Nonetheless, I really think the kernel needs to allow for the android > way of power saving. It misses out on a big feature and a big user-base > if not. Let's get rid of hypothetical uses in the future: suspend blockers is _only_ used by Android user-space. Nobody else has expressed any intention of using them. > Also I expect there to be synergies between android development and > mainline kernel development _only_ if android development can use > mainline kernel. That's like saying "there can only be synergies between linux real time and mainline _only_ if RT development can use mainline". I can give you my experience at Nokia... can you use mainline on any of the Maemo devices? No. You have to patch the kernel heavily, to be able to kind-of run the official user-space, or you have to use a different user-space. Does that prevent synergies? No. As Brian Swetland and Daniel Walker already expressed before; you can run mainline kernel with debian on Android phones. It would be nice to run Android user-space, or parts of it on mainline kernels, but if it's not possible, that's a deficiency on Android's design; Maemo/Moblin/Meego are good players in the linux ecosystem so you can re-use parts of the system on typical desktops (in fact many are coming from there), and there are community distributions re-using those parts and running just fine on mainline kernels. Sure, it would be easier for Android developers if all their crap was in the mainline, but even then there are no guarantees of anything. Just like any other linux phone, you'll probably need to add patches for 3D drivers, DSP, or other hardware acceleration, missing board-specfic patches, and bunch of hacks. So if you have to add all those patches anyway, what's the problem of having to add the suspend block patches? Why do some Android developers think they can be the exception and have patches merged in the core of linux _only_ for their specific user-space, and their specific drivers? If you separate suspend blockers from Android, and judge them on their technical merit, I don't see a single person saying this is a good idea, we'll switch all our user-space to use them. -- Felipe Contreras -- 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
