On Mon, 2011-08-08 at 23:31 +0200, Rafael J. Wysocki wrote:

On Sunday, August 07, 2011, Mark Brown wrote:

quoted

OK, so this does sound like there's probably a genuine issue on PCs due
to limitations in the environment.  Is it possible to expose these
things to userspace in a way that's limited to the affected platforms?

Well, in principle we could make it depend in CONFIG_ACPI or something like
this, but I'm not sure that will be well-received. :-)

Or the drivers for the particular buses in use?

quoted

That does sound like a fair characterization for PCs.  For embedded
systems where we have a *much* better knowledge of the hardware we're
running on you're just working with the basics of what the hardware
needs to run - the hardware needs whatever it needs and no matter what
you think of the quality of the hardware there's an expectation that the
kernel is ging to be able to work.

In the particular case in question, though, there's some freedom.  Namely,
the hardware will work for many different QoS constraints and it's not
precisely known in principle and upfront which one would be optimal for
a given workload.

But are these tunings things that we can usefully represent in a generic
API or are they specific parameters of the subsystem in question? I
don't think anyone has suggested that having tuning for things where
there are genuine choices is a good thing.

quoted

As I've said it's not the fine tuning that I'm worried about, it's the
specific mechanism that's being suggested.  Being able to tune things in
a way that's relevant to the device being tuned seems entirely sensible.

Do you know any better mechanism consistent accross all devices?
Please be specific. :-)

Well, I'm suggesting that we shouldn't have a standard userspace API for
this in the first place but should instead be doing things on the
subsystem or driver level. I'm not sure we can sensibly do anything that
works usefully for all devices.

quoted

Realistically if you're in a position where you need to work at this
very low level on an embedded device you can replace the entire firmware
on the device.  We don't want to end up in the situation where we've got
kernel support for a device and the only way to get it to actually run
sensibly is to install the silicon vendor's proprietary userspace, and
we especially don't want to end up in the situation where that userspace
is using standard and supported kernel interfaces to do its thing.

Well, the wakelocks example shows clearly that preventing certain interfaces
from being merged into mainline doesn't actually prevent people from using
them in actual products.  I claim it's way better if a vendor uses its
proprietary user space with the mainline kernel than if that vendor patches
the kernel and _then_ uses its proprietary user space with it.  Your
argumentation seems to suggest that we encourage the latter.

We can't stop people doing questionable things out of tree but that
doesn't mean lowering standards in mainline is a good idea. Keeping
things out of tree creates a range of costs - the effort required to
write the code and update for new kernel releases, support issues when
the out of tree code causes problems and so on - and makes it clear to
people using the code where the costs came from. If the code looks like
it's standard code using standard interfaces much of that pressure goes
away.

This is similar to all the stuff that's going on in the ARM tree at the
minute - there's nothing we can do to prevent vendors shipping random
code of any quality in out of tree BSPs but we can set high standards
for the quality of code we accept into mainline and let the resulting
pressures push people towards mainline solutions.