On Fri, Aug 13, 2010 at 6:22 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
quoted text
> On Thu, Aug 12, 2010 at 10:34:47PM +0300, Felipe Contreras wrote:
>> "PM-driving applications" is a new invention, so how do you know if an
>> application belongs to this category or not? Some application might be
>> non-PM-driving most of the time, but suddenly become PM-driving. Well,
>> you have to analyze *all* of them.
>
> A PM-driving application is one that exerts control over the system's
> power state.  In the case of Android, a PM-driving application is one
> that is permitted to acquire suspend blockers.

I already mentioned that a "PM-driving application" might not have
suspend-blockers; because the user denied them, or because the
developer forgot them.

quoted text
>> Think about this... is bash a PM driving application? No, but what if
>> you run: 'sleep 3600 && alarm.sh'.
>
> That is an excellent example, as it applies equally to dynamic power
> management.  By how much are you allowed to delay the wakeup?

Huh? Certainly not days, which if Android guys are right, might be how
much the task will be delayed.

quoted text
>> Perhaps I should rewrite that as:
>> 2) if suspend blockers are enabled in the system; *all* user-space is affected
>
> That is speculation on your part.

Not really. Say you have 100 packages in your system, how do you know
which ones would be PM-driving? Can you grep for something, or see if
they open certain file? No, you have to analyze them one by one; they
*all* are affected, although not all might require modifications.

But assuming I'm wrong, that's precisely the reason why a practical
exercise would help.

quoted text
>> This "requirement" is specific to Android's user-space, isn't it?
>
> That is your speculation.

Which is why we need something practical.

quoted text
>> Not Ubuntu, not Fedora, not MeeGo, not anyone with a typical
>> user-space seems to be having this problem. I can argue to you that
>> this problem can be solved in easier ways, but instead I will argue
>> that perhaps we should wait for somebody besides Android to complain
>> about it before providing a "solution". Because after all, what good
>> is a "solution" provided by the kernel, if the user-space is not going
>> to use it, ever.
>
> At this point in the discussion, I am quite prepared to believe that you
> will avoid using suspend blockers, and that you will further do everything
> in your power to prevent anyone else from using suspend blockers.  ;-)

I'm not tying anybody's hands.

How are people using real-time linux if it's not on mainline? Well,
duuh, you apply the patches. If say Fedora was interested on it, they
could apply the patches, and see for themselves. People do that all
the time, with the mm tree, with Con Koliva's patches, etc. Once
people are happy with the results, things get merged. Why should this
be any different?

-- 
Felipe Contreras
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/