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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Saturday, August 20, 2011, Mark Brown wrote:
> On Sat, Aug 20, 2011 at 06:51:42PM +0200, Rafael J. Wysocki wrote:
> > On Saturday, August 20, 2011, Mark Brown wrote:
> 
> > > Coming at this from the embedded perspective modifying the kernel just
> > > isn't an issue.  It's quite depressing in other cases too but some of
> > > the circumstances you mentioned in previous messages are sensible do
> > > make sense to me.  It does seem like this is a system specific problem
> > > which we should be able to enable as part of the support for those
> > > systems.
> 
> > I don't think that's platform-specific in general.  For example, there are
> > devices that don't really belong to any media-streaming-alike framework
> > and we may (and probably will) want to use PM QoS with them, because they
> > may be included in PM domains and influence power management of other
> > devices.  Think of a serial console.
> 
> Using PM QoS doesn't seem platform specific of course.  Having userspace
> need to go in and do per-device overrides in order to get things working
> does.
> 
> > > > without modifying the kernel.  Also, it will help to test and debug new drivers
> > > > and subsystems.
> 
> > > If it were a debugfs facility I'd not be concerned.
> 
> > If that's going to be per-device, it really is much easier to put it into
> > sysfs (we already have per-device PM debug interfaces in there).  It may
> > depend on CONFIG_PM_ADVANCED_DEBUG or something like this, though, at least
> > to start with.
> 
> Yeah, the debugfs device attachment stuff is slightly annoying but it's
> fairly straightforward to create an appropriate heirachy - there's
> several subsystems doing that sort of stuff by using dev_name().

I'm not a big fan of that, sorry.  Besides, as I said, we already have
debug PM interfaces in sysfs, so I don't see the reason not to add
another one.

> > > That's not really a problem - if people are adding their own crazy
> > > interfaces it's clear that they've done that.  It'll show up as a red
> > > flag to anyone looking at their stuff and this will create pressure on
> > > them to fix their code or at least do a better job for the next thing.
> 
> > > The goal isn't to tie people's hands to stop them doing silly things,
> > > it's to make it clear that that is what they're doing.
> 
> > The same applies to using kernel interfaces.  If someone uses a sane
> > interface for doing crazy stuff, that's their problem and should show
> > up as a red flag just as well.
> 
> The big problem I'm seeing here is that there's nothing about having
> userspace do all the knob twiddling that looks crazy just from looking
> at the system.  The controls are there and in the standard kernel
> interface, it's not like there's any ABIs or large piles of in kernel
> code that need to be added (if anything the in kernel code should look
> simpler as there's less going on).

Well, I'm kind of not seeing that as a big problem.  At least, this is not
a technical issue, but a social one.

Thanks,
Rafael