On Sat, Jun 5, 2010 at 10:04 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Saturday 05 June 2010, Felipe Contreras wrote: >> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <florian@xxxxxxxxxxx> wrote: >> > On Mon, 31 May 2010 22:12:19 +0200 >> > Florian Mickler <florian@xxxxxxxxxxx> wrote: >> >> If I have a simple shell script then I don't wanna jump through >> >> hoops just to please your fragile kernel. >> > >> > Also why should that code on one device kill my uptime and on the >> > other machine (my wall-plugged desktop) work just well? That doesn't >> > sound right. >> >> Sounds perfectly right to me; one code runs perfectly fine on one >> machine, and on the other doesn't even compile. Well, sure, it wasn't >> written with that use-case in mind. >> >> > Clearly opportunistic suspend is a workaround for battery-driven devices >> > and no general solution. But it is not specific to android. At least >> > not inherently. It could be useful for any embedded or mobile device >> > where you can clearly distinguish important functions from convenience >> > functions. >> >> Yes, it could, but why go for the hacky solution when we know how to >> achieve the ideal one? >> >> > I really can't understand the whole _fundamental_ opposition to this >> > design choice. >> >> Nobody is using it, except Android. Nobody will use it, except Android. > > That's like saying "Android is not a legitimate user of the kernel". Is that > you wanted to say? Read the context: opportunistic suspend, which is considered a workaround, which requires new user-space API for suspend blockers, might be remotely considered for inclusion *if* it indeed solves a problem for battery-driven devices, which other parties also experience and could benefit from this solution. The answer: no, it doesn't: only Android user-space will benefit from it. >> I have seen recent proposals that don't require changing the whole >> user-space. That might actually be used by other players. > > Sure, an approach benefitting more platforms than just Android would be better, > but saying that the kernel shouldn't address the Android's specific needs as a > rule if no one else has those needs too is quite too far reaching to me. There are no Android specific needs, why should certain user-space ecosystem need certain API that somehow *nobody* else does? I think in this huge thread it has become obvious that people are reluctant to this idea... whatever problem Android user-space presents (I don't think there's any), it can be solved for "he rest of the world" too, and such generic solution is worth exploring. -- 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
