> > 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. Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to see some fixes be appropriately in-kernel; maybe not many though. When reading about this suspend block stuff, does anyone else hear eachoes of APM? It's been ages since that was used, but ISTR it also leveraged handshaking between kernel and userspace. Are there lessons to be applied from there to this discussion? On first principles, I don't see anything wrong with acknowledging that the kernel doesn't have a "whole system PM view" and thus its PM knowledge could usefully be augmented by information from userspace (applications), possibly on request. Just what that broad PM view consists of gets kind of system-specific. For OMAP hardware, with smart device-level power reduction active almost all the time, it may look different from an ACPI laptop where the BIOS is biased towards saving device power primarily in some suspend state(s) ... or some other hardware platform without much hardware or BIOS assist, where the main PM mechanisms involve software detection/instigation of hardware idleness (and potentially "off-ness"). > And you will continue doing that once the Meego app store > has 100k apps? I may have overlooked it, in one of the 100K messsages in my mailbox about versions of suspend block/etc patches ... But surely NOBODY is actually contending that broken aps NOT get fixed?? It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools. (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.) Once such hogs get identified they will need to get fixed. Any other proposal seems broken to me... -- 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
