[PATCH 0/8] Suspend block api (version 8)
in [Kernel]
|
Prev: [ANN] Linux Security Summit 2010 - Announcement and CFP
Next: [PATCH 4/8] PM: suspend_block: Add debugfs file
From: Peter Zijlstra on 5 Jun 2010 16:00 On Sat, 2010-06-05 at 21:39 +0200, Rafael J. Wysocki wrote: > > There is a number of kernel users that depend on Android user space > (phone vendors using Android on their hardware, but providing their own > drivers), so I don't think we really can identify Android with Google in that > respect. I don't see why we can't merge the platform code and drivers without suspend blockers. Google can patch them back in on their side if they want to. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Felipe Contreras on 5 Jun 2010 16:00 On Sat, Jun 5, 2010 at 10:49 PM, Florian Mickler <florian(a)mickler.org> wrote: > On Sat, 5 Jun 2010 20:16:33 +0300 > Felipe Contreras <felipe.contreras(a)gmail.com> wrote: >> New users will see it has low score; they will not install it. That's >> a network effect. >> >> Having users is the quintessential reason people write code. > > That is nice. But how does it impact the problem that suspend blockers > solve? And why do suspend blockers interfere with that? It doesn't, I don't know why people keep bringing this argument, I just though it should not be left open as a valid one. I should have mentioned that this is indeed irrelevant. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 5 Jun 2010 16:00 On Sat, 5 Jun 2010 20:30:40 +0300 Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > On Thu, Jun 3, 2010 at 6:28 PM, Peter Zijlstra <peterz(a)infradead.org> wrote: > > On Thu, 2010-06-03 at 16:12 +0200, Florian Mickler wrote: > >> On Thu, 03 Jun 2010 09:40:02 +0200 > >> Peter Zijlstra <peterz(a)infradead.org> wrote: > >> > >> > Fix the friggin apps, don't kludge with freezing. > >> > >> Of course programs should be as smart as possible. But that is an > >> orthogonal problem. > >> > >> Suppose firefox were fixed. It still needs to fetch my rss feeds every > >> minute, because I'm sad if it doesn't. It just can't be fixed at the > >> application level. > > > > Sure it can, why would it need to fetch RSS feeds when the screen is off > > and nobody could possible see the result? So you can stop the timer when > > you know the window isn't visible or alternatively when the screensaver > > is active, I think most desktops have notification of that as well. > > Exactly, and that's what applications in the N900 do. For this to work > reliably, you need these notifications (network disconnected, screen > off) to be easily accessible, and even transparent to the application > writer. > > I don't think the suspend blockers solve much. A bad application will > behave bad on any system. Suppose somebody decides to port Firefox to > Android, and forgets to listen to the screen off event (bad on Android > or Maemo), however, notices the application behaves very badly, so by > googling finds these suspend blockers, and enables them all the time > the application runs. > > When the user install the application, will be greeted by a warning > "This application might break PM, do you want to enable suspend > blockers?" (or whatever), as any typical user would do, will press Yes > (whatever). > > We end up in exactly the same situation. > No. The application will show up in the suspend blocker stats and the user will remember: "Oh, yes. There was a warning about that. Well I think I'm going to file a bug there." The only difference is, that with suspend blockers, he can than dismiss the applications permission to block suspend and will not miss his job interview the next day because his phones battery run out. And also he can use the application to a certain extent. Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Felipe Contreras on 5 Jun 2010 16:00 On Sat, Jun 5, 2010 at 10:04 PM, Rafael J. Wysocki <rjw(a)sisk.pl> wrote: > On Saturday 05 June 2010, Felipe Contreras wrote: >> On Mon, May 31, 2010 at 11:47 PM, Florian Mickler <florian(a)mickler.org> wrote: >> > On Mon, 31 May 2010 22:12:19 +0200 >> > Florian Mickler <florian(a)mickler.org> 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 5 Jun 2010 16:10
On Sat, 5 Jun 2010 20:44:24 +0300 Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > 2010/6/2 Arve Hj�nnev�g <arve(a)android.com>: > > 2010/6/2 Peter Zijlstra <peterz(a)infradead.org>: > >> (and please don't mention @#$@ up x86 ACPI again, Intel knows, they're > >> fixing it, get over it already). > >> > > > > I don't think it is realistic to drop support for all existing hardware. > > We are talking about mainline here, there's no support for suspend > blockers, so nothing is dropped. > > In the mind of everybody, suspend blockers is for opportunistic > suspend, which only makes sense on sensible hw (not current x86). So > in the mind of everybody, x86 should be out of scope for the analysis > of suspend blockers. > > Are you seriously suggesting that one of the strong arguments in favor > of suspend blockers is x86 usage (nobody agrees)? If not, then drop > it. I think they have an advantage over the 30-minute-screensaver-then-suspend that current desktops do. Because you can define what keeps the system up. I.e. the screensaver/powermanager is not limited to keyboard- and mouse-inactivity. > If I enable suspend blockers on my laptop, I have to modify my > user-space. Otherwise my system will behave horribly. > In the simplest case you have a shell script which takes a suspend blocker and reads from stdinput. When you write "mem" to it, it releases the suspend blocker and acquires it back again. Voila, forced suspend reimplemented on top of opportunistic suspend. That wasn't hard, was it? Cheers, Flo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |