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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
