> Really, what are you getting at? Do you deny that there are programs,
The problem you have is that this is policy. If I have the device wired
to a big screen and I want cows bouncing on it I'll be most upset if
instead it suspends. What you are essentially arguing for is for the
kernel to disobey the userspace. It's as ridiculous (albeit usually less
damaging) as a file system saying "Ooh thats a rude file name, the app
can't have meant it, I'll put your document soemwhere else"
The whole API feels wrong to me. It's breaking rule #1 of technology "You
cannot solve a social problem with technology". In this case you have a
social/economic problem which is crap code. You solve it with an
economics solution - creative incentives not to produce crap code like
boxes that keep popping up saying "App XYZ is using all your battery" and
red-amber-green powermeter scores in app stores.
That said if you want technical mitigation I think it makes more sense
if you look at it from a different starting point. The starting point
being this: We have idling logic in the kernel and improving this helps
everyone. What is needed to improve the existing logic ?
- You don't know which processes should be ignored for the purpose of
suspend (except for kernel threads) and there is no way to set this
- You don't know whether a move from a deep idle to a 'suspend' (which is
just a really deep idle in truth anyway) might break wakeups
requirements because a device has wake dependencies due to hardware
design (eg a port that has no electronics to kick the box out of
suspend into running). This is a problem we have already. [1]
That maps onto two existing ideas
Sandboxing/Resource Limits: handling apps that can't be trusted. So the
phone runs the appstore code via something like
setpidle(getpid(), something);
exec()
where 'something' is a value with meaning to both user space and to the
existing idling logic in the kernel that basically says to what extent it
is permitted to block idling/suspend. That also seems to tie into some of
the realtime + idle problems. This I think deals with Kevin Hillman's
thoughts on dealing with untrustworthy app code more cleanly and avoids
the need for userspace hackery like the blocker API.
And an entirely in kernel API where device drivers can indicate that in
their current situation they require that the power level doesn't drop
below some limit unless user requested. This is really important because
the platform vendor of the phone/pda/tablet whatever effectively owns the
kernel - so it's *their* problem, *their* control, *their* hardware and
they can make it work as best for the device. Best of all it means its
all free software stuff so if the vendor screws up you can still fix your
phone.
Implementation-wise it probably ties into setpidle, its simply that a task
has a pair of idle values, a dynamic one and a base one, the dynamic one
being the base one but updatable temporarily by drivers.
Alan
--
[1] Note I disagree with Kevin here on static/dynamic power management.
There are IMHO two types of PM but they are 'user invoked' and
'automatic'. "Static" simply means it's not been made fast enough yet but
its just a policy divide dependant on the users 'acceptable' resume time
(which for hard RT may just as well rule out some more usual power states)
--
