> I don't see the need for inventing a notion of rings.  Apps can be entrusted with particular 
> permissions.  They're trusted to the extent of the permissions granted.  There are some privileges 
> like telephony that we may only grant to apps pre-installed on the device, up to vendors.

It seems to me that it's not useful to distinguish between a lot of these mission-critical permissions.  As soon as an app has permission to use a ring-zero API, then it is able to make the phone useless and we need to review its code.  And if we're reviewing its code, then we don't need to use gecko to restrict what it does.

Note that this could be an implementation detail; that is, ring-zero can be an internal gecko designation.  We could still have a bunch of separate specs and the notion that you need permission for each one separately, but it could be that gecko always grants permission for these specs as a unit.

But anyway, this is an orthogonal discussion which we can have when we finally implement the permissions framework.  I don't feel too strongly about this; I just think it'll be easier to have fewer permission bits.

> Are you saying that there should only be one application given screen-management permissions?  

No.  I don't want our architecture here to force Gaia/Gaia-alternative developers to implement their front-end in any particular way.

> If there's a use case for multiple apps having screen-management perms (maybe there isn't), then 
> we should consider how they're supposed to interact.

What I'm saying is that the screen-management API shouldn't try to be intelligent about what happens when multiple apps call it.  If one app sets screen.enabled = false and another app sets screen.enabled = true then last writer wins, just as though if Gecko code called Hal::SetScreenEnabled(false) followed by Hal::SetScreenEnabled(true).

The reason I argue that the API doesn't need to do something more clever here (such as, as you suggested, adding another level of indirection so that all these screen.enabled modifications get funneled down to a single power manager app) is that we trust the code which is able to modify screen.enabled.

> An idle notification sounds like a generally useful thing.  Has anyone proposed this before?  It 
> sounds easy to spec and implement.

I talked with people about this at the last work-week, but I don't know if you were there.  I'd like to design the API only once we have a consumer, though.  So once the front-end people are ready for it, we can design it.  (For example, it might make sense to register a callback which says "notify me when the device has been idle for X seconds, or when there are no more wake locks with topic T held, whichever comes last.")

> Now, along with that, if we specify what happens if an app with screen-management permissions 
> tries to set screen.enabled = false when there are active screen-on wakelocks or tries to change 
> brightness when there's a screen-brightness lock, then you've convinced me we've got all we need 
> to implement this entirely in "userspace".

screen.{brightness,enabled} are low-level functions, and at least the screen/brightness wakelocks are advisory to the screen management code.  The screen code is free to ignore the wake locks and enable/disable/dim the screen at will.  Otherwise, it can't turn off the screen when the user presses the power button!

Even for functionality whose wake-locks interact with the kernel, we're still going to need a way for the power manager to hard-disable it.  For example, when you go into airplane mode, we have to turn off the 3G radio, even if a 3G wake lock is held.