[PATCH 0/8] Suspend block api (version 6)
in [Kernel]
|
Prev: [PATCH 8/8] power_supply: Block suspend while power supply change notifications are pending
Next: [PATCH 7/8] Input: Block suspend while event queue is not empty.
From: Matthew Garrett on 13 May 2010 17:30 On Thu, May 13, 2010 at 02:10:06PM -0700, Tony Lindgren wrote: > * Matthew Garrett <mjg(a)redhat.com> [100513 13:29]: > > And if that's the application that's listening to the network socket > > that you want to get a wakeup event from? This problem is hard. I'd love > > there to be an elegant solution based on using the scheduler, but I > > really don't know what it is. > > Your system should wake up to an interrupt in that case. Then you have > the trusted apps running that can decide if the untrusted apps should > be continued or not. What race-free mechanism do you use to ensure that? It's very easy to handwave these problems away. It's very difficult to actually write an implementation that works. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- 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 13 May 2010 17:30 On Thursday 13 May 2010, Daniel Walker wrote: > On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote: > > On Thursday 13 May 2010, Matthew Garrett wrote: > > > On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: > > > > On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: > > > > > See feature-removal-schedule.txt. So far we have no indication that it's > > > > > going to be replaced, because nobody has actually suggested a working > > > > > way to do this better. If we had a concrete implementation proposal for > > > > > that then we'd be in a pretty different position right now. > > > > > > > > Ok, feature-removal-schedule.txt applies to everything tho. What your > > > > saying is that if this interface only last a short time it might take 6 > > > > months, if it last for a long time it would take longer. There's no easy > > > > way to know that Google is the only user after some amount of time > > > > passes. > > > > > > If the interface is there for a long time, it's because we haven't come > > > up with anything better. And if we haven't come up with anything better, > > > the interface deserves to be there. > > > > Moreover, the interface is already in use out-of-tree and that usage is > > actually _growing_, so we have a growing number of out-of-tree drivers that > > aren't megrgeable for this very reason. > > Why can't we merge the drivers? Drivers are just drivers, they don't > need this to get merged. (They need it to work with Android) Because someone would have to remove suspend blockers (or rather wakelocks) from the drivers, test that they work correctly without suspend blockers and submit the modified versions. Going forward, every party responsible for such a driver would have to maintain an out-of-tree version with suspend blockers (or wakelocks) anyway, so the incentive to do that is zero. Practically, as long as the opportunistic suspend is out of tree, there will be a _growing_ number of out-of-tree drivers out there, which is not acceptable in the long run. 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: Tony Lindgren on 13 May 2010 17:30 * Rafael J. Wysocki <rjw(a)sisk.pl> [100513 14:16]: > On Thursday 13 May 2010, Matthew Garrett wrote: > > On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: > > > * Matthew Garrett <mjg(a)redhat.com> [100513 13:03]: > > > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > > > > > > > > > The system stays running because there's something to do. The system > > > > > won't suspend until all the processors hit the kernel idle loop and > > > > > the next_timer_interrupt_critical() returns nothing. > > > > > > > > At which point an application in a busy loop cripples you. > > > > > > Maybe you could deal with the misbehaving untrusted apps in the userspace > > > by sending kill -STOP to them when the screen blanks? Then continue > > > when some event wakes up the system again. > > > > And if that's the application that's listening to the network socket > > that you want to get a wakeup event from? This problem is hard. I'd love > > there to be an elegant solution based on using the scheduler, but I > > really don't know what it is. > > I agree and I don't understand the problem that people have with the > opportunistic suspend feature. It seems to be picking quite a few comments for one. > It solves a practical issue that _at_ _the_ _moment_ cannot be solved > differently, while there's a growing number of out-of-tree drivers depending > on this framework. We need those drivers in and because we don't have any > viable alternative at hand, we have no good reason to reject it. Nothing is preventing merging the drivers can be merged without these calls. Regards, Tony -- 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 13 May 2010 17:30 On Thursday 13 May 2010, Matthew Garrett wrote: > On Thu, May 13, 2010 at 01:23:20PM -0700, Tony Lindgren wrote: > > * Matthew Garrett <mjg(a)redhat.com> [100513 13:03]: > > > On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: > > > > > > > The system stays running because there's something to do. The system > > > > won't suspend until all the processors hit the kernel idle loop and > > > > the next_timer_interrupt_critical() returns nothing. > > > > > > At which point an application in a busy loop cripples you. > > > > Maybe you could deal with the misbehaving untrusted apps in the userspace > > by sending kill -STOP to them when the screen blanks? Then continue > > when some event wakes up the system again. > > And if that's the application that's listening to the network socket > that you want to get a wakeup event from? This problem is hard. I'd love > there to be an elegant solution based on using the scheduler, but I > really don't know what it is. I agree and I don't understand the problem that people have with the opportunistic suspend feature. It solves a practical issue that _at_ _the_ _moment_ cannot be solved differently, while there's a growing number of out-of-tree drivers depending on this framework. We need those drivers in and because we don't have any viable alternative at hand, we have no good reason to reject it. 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: Tony Lindgren on 13 May 2010 17:40
* Daniel Walker <dwalker(a)fifo99.com> [100513 14:28]: > On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: > > > Because someone would have to remove suspend blockers (or rather wakelocks) > > from the drivers, test that they work correctly without suspend blockers and > > submit the modified versions. Going forward, every party responsible for such > > a driver would have to maintain an out-of-tree version with suspend blockers > > (or wakelocks) anyway, so the incentive to do that is zero. > > They should work without wakelock since wakelock are optional .. I mean > there's nothing in suspend blockers I've seen that indicates it's > required for some drivers to work. So it's just a matter of patching out > the wakelocks, with no need to re-test anything. > > You get the driver mainlined, then maintain a small patch to add > wakelocks. Not hard at all , with lots of incentive to do so since you > don't have to maintain such a large block of code out of tree. > > > Practically, as long as the opportunistic suspend is out of tree, there will be > > a _growing_ number of out-of-tree drivers out there, which is not acceptable > > in the long run. > > I don't see why your saying that. These driver should work with out all > of this, which means they can get mainlined right now. I agree with Daniel here. We should keep merging the drivers separate from the suspend blocks issues. Regards, Tony -- 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/ |