[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: Felipe Contreras on 5 Jun 2010 13:50 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. >>> Unrelated to >>> Android, I also want to use opportunistic suspend on my desktop. >> >> So you're going to sprinkle this suspend blocker shite all over regular >> userspace? > > I have said several times, that regular user-space will not need to be > modified to maintain their current behavior. If I enable suspend blockers on my laptop, I have to modify my user-space. Otherwise my system will behave horribly. -- 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: Rafael J. Wysocki on 5 Jun 2010 15:10 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? > 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. Rafael -- 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: Peter Zijlstra on 5 Jun 2010 15:20 On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote: > > > 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. Well, if the android people keep rejecting all sensible approaches to power savings except their suspend blocker mess, then I don't see why we should support their ill designed mess. We should strive to provide an interface that can be used by all interested parties to conserve power; if Android really is the only possible user of the interface then I don't see any reason at all to merge it, they might as well keep it in their private tree. -- 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: Rafael J. Wysocki on 5 Jun 2010 15:40 On Saturday 05 June 2010, Peter Zijlstra wrote: > On Sat, 2010-06-05 at 21:04 +0200, Rafael J. Wysocki wrote: > > > > > 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. > > Well, if the android people keep rejecting all sensible approaches to > power savings except their suspend blocker mess, then I don't see why we > should support their ill designed mess. Well, I certainly would like the Android people to be more appreciative of our ideas if they expect reciprocity. > We should strive to provide an interface that can be used by all > interested parties to conserve power; if Android really is the only > possible user of the interface then I don't see any reason at all to > merge it, they might as well keep it in their private tree. 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. Rafael -- 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:16:33 +0300 Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > On Tue, Jun 1, 2010 at 12:14 AM, Rafael J. Wysocki <rjw(a)sisk.pl> wrote: > > Do you realistically think that by hurting the _user_ you will make the > > _developer_ write better code? �No, really. > > As an application writer, if my users complain that their battery is > being drained (as it happened), they stop using it, and other people > see there are problems, so they stop using it, if people get angry > about it they will vote it down. > > 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? 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/ |