Re: [PATCH 02/11] PM: extend PM QoS with per-device wake-up constraints

On Friday, August 05, 2011, Mark Brown wrote:

On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:

quoted

On Thursday, August 04, 2011, Mark Brown wrote:

quoted

quoted

On the one hand that's true.  On the other hand that just seems like
going down a bad road where we have drivers that only work when run with
a magic userspace that may or may not be published which is just going

quoted

First off, we're doing this already (user space can block runtime PM, for
one example, because there are systems where runtime PM doesn't work
although it works on other systems with analogous hardware and pretty
much the same set of drivers).

Yeah, I've never been terribly convinced about that and for the things
that drivers need to manualy implement (like wake configuration) it's
widely ignored.

quoted

Second, I think there are valid use cases in which user space _really_ knows
better than the kernel.  I'm opposed to the idea that users shouldn't be given
control of their systems, because they may not know what they're doing.

Do you have any examples of this that aren't better expressed in device
specific terms?

I'm not sure what you mean exactly, but if you take two PC-like systems
with similar hardware configurations, but different BIOS-es and motherboard
layouts, it's very likely that on one of them PCI PME won't be routed
correctly, for example.  In that case the kernel has no way to figure out
that that system is broken, the problem can only be worked around from user
space by diabling runtime PM on the affected PCI devices.  I expect similar
problems to appear for the PM QoS settings.

It's not that users don't know what they're doing, it's
that working around system integration and stability issues in userspace
isn't really progressing things well or helping with maintainability.

No, it's not, but sometimes we simply don't have the choice.  Besides,
in the particular case of PM QoS, the constraints set by user space will
simply be added to the constraints set by kernel subsystems.  Thus they
won't prevent any kernel subsystem from specifying its own constraints,
but they will give user space the option to override the constraints
originating from the kernel.

Generally if the user has sufficient access to be able to do anything
with this stuff they've got just as much access to the kernel as to
userspace.

Do you mean they may rebuild the kernel?  That isn't always possible.

Thanks,
Rafael