[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: Felipe Balbi on 19 May 2010 03:30 On Tue, May 18, 2010 at 03:59:48PM +0200, ext James Bottomley wrote: >On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote: >> On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote: >> >Right, because Firmware writers are from the rugged unresponsive uplands >> >of planet >> >ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and >> >Software writers are from the emollient responsive groves of planet >> >harmony. Obviously what would work for one wouldn't work for the other. >> > >> >As a software writer, I fully buy into that world view. The trouble is >> >that when I go to dinner with hardware people, they seem to be awfully >> >nice chaps ... almost exactly like me, in fact ... >> >> what does this add to suspend_blockers discussion ? > >Sorry I was evidently being too subtle. > >The point is that if, as you acknowledge, that you can't train firmware >engineers to be responsive, there's no reason to think you can train >software engineers in the same quality ... they're very similar people. I wouldn't say it's up to the engineer himself, it's more related to how the company that person works for deal with such things. >The corollary is that real world systems have to operate in the face of >misbehaving hardware *and* software. I still think the kernel shouldn't deal with broken applications and we shouldn't try to fix them in kernel space. We can, of course, try to find them and have all sorts of bells and whistles shouting 'process %s is preventing CPU from sleeping for %llu nanoseconds' or something like that. -- balbi DefectiveByDesign.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 19 May 2010 16:50 On Wednesday 19 May 2010, Felipe Balbi wrote: > On Tue, May 18, 2010 at 03:59:48PM +0200, ext James Bottomley wrote: > >On Tue, 2010-05-18 at 09:40 +0300, Felipe Balbi wrote: > >> On Mon, May 17, 2010 at 09:49:35PM +0200, ext James Bottomley wrote: > >> >Right, because Firmware writers are from the rugged unresponsive uplands > >> >of planet > >> >ignore-user-complaints-and-eat-them-for-breakfast-if-they-file-bugs and > >> >Software writers are from the emollient responsive groves of planet > >> >harmony. Obviously what would work for one wouldn't work for the other. > >> > > >> >As a software writer, I fully buy into that world view. The trouble is > >> >that when I go to dinner with hardware people, they seem to be awfully > >> >nice chaps ... almost exactly like me, in fact ... > >> > >> what does this add to suspend_blockers discussion ? > > > >Sorry I was evidently being too subtle. > > > >The point is that if, as you acknowledge, that you can't train firmware > >engineers to be responsive, there's no reason to think you can train > >software engineers in the same quality ... they're very similar people. > > I wouldn't say it's up to the engineer himself, it's more related to how > the company that person works for deal with such things. > > >The corollary is that real world systems have to operate in the face of > >misbehaving hardware *and* software. > > I still think the kernel shouldn't deal with broken applications and we > shouldn't try to fix them in kernel space. We can, of course, try to > find them and have all sorts of bells and whistles shouting 'process > %s is preventing CPU from sleeping for %llu nanoseconds' or something > like that. Please note that this approach is not too practical for vendors who ship systems like cell phones to the general public. 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 20 May 2010 01:20 On Wed, 19 May 2010 09:59:34 +0300 Felipe Balbi <felipe.balbi(a)nokia.com> wrote: > >The corollary is that real world systems have to operate in the face of > >misbehaving hardware *and* software. > > I still think the kernel shouldn't deal with broken applications and we > shouldn't try to fix them in kernel space. We can, of course, try to > find them and have all sorts of bells and whistles shouting 'process > %s is preventing CPU from sleeping for %llu nanoseconds' or something > like that. > But with that, you still shift the burden of exchanging that app with an feature-equivalent non-broken version to the user. which is not user friendly and not necessary if you have a "smart" enough kernel. 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 Balbi on 20 May 2010 01:20 Hi, On Wed, May 19, 2010 at 10:42:55PM +0200, ext Rafael J. Wysocki wrote: >Please note that this approach is not too practical for vendors who ship >systems like cell phones to the general public. yeah, tell me about it :-p during development on MeeGo devices we try to tackle down as much as possible the use_time offenders and start by filing bugs to those apps, instead of fixing their issues in kernel space. if suspend_blockers could at least be transparent to applications, then it wouldn't be the best scenario but at least applications wouldn't have to be specially written to support that. And like I said, if anyone can hold a suspend_blocker forever the idea of "improving use_time" is easy to break, but then someone replied "anyone holding a suspend_blocker will show up in UI", and again I say you don't need suspend_blockers to have a fancy UI showing which processes are waking up the processor. Powertop already gathers that information, you just need to make a fancy UI around it. -- balbi DefectiveByDesign.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: Felipe Balbi on 20 May 2010 05:00
On Thu, May 20, 2010 at 07:15:28AM +0200, Florian Mickler wrote: > But with that, you still shift the burden of exchanging that app with > an feature-equivalent non-broken version to the user. > which is not user friendly and not necessary if you have a "smart" > enough kernel. and _without that_, you shift the burden of having a working power management completely into the kernel. Forcing the kernel to deal with completely broken apps. What will happen is that apps developers won't boder thinking about power consumption since the kernel is "smart" enough to "fix" their mess. To me that's much bigger burden to the kernel than the other option is to apps. -- balbi -- 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/ |