> I think the suggestion that has the closet fit with what we're trying
I think we ended up in the same place on our own.
With latency you have an "I don't give damn" latency in your model which
we could describe as infinite or "manyana" perhaps.
I am much much less concerned about general expressions of constraint
appearing in drivers. One of my early mails gave a list of other
people/projects/problems that need them - from hard real time, to high
speed serial on low end embedded to virtualisation.
They fix a general problem in terms of a driver specific item. We end up
making changes around the tree but we make everyone happy not just
Android. Also we are isolating policy properly. The apps and drivers say
"I have these needs", the power manager figures out how to meet them.
Where it gets ugly is if you start trying to have drivers giving an app a
guarantee which the app then magically has to know to dispose of.
If you are prepared to exclude untrusted apps from perfectly reliable
event reporting (ie from finger to application action) that doesn't seem
to be a neccessity anyway.
Priority inversion with the cgroup case is like synchronization effects
with the suspend blockers - its a real ugly problem and one that is known
to be hard to fix if you let it happen so I agree there.