Re: Changes to PM layer break userspace

On Tue, Dec 19, 2006 at 07:59:42PM -0800, David Brownell wrote:
On Tuesday 19 December 2006 4:25 pm, Matthew Garrett wrote:
1) feature-removal-schedule.txt says that it'll be removed in July 2007.
This isn't July 2007.

Which is why the functionality is still there.

Merely broken in the majority of cases...

2) The functionality was disabled in 2.6.19. The addition to
feature-removal-schedule.txt was in, uh, 2.6.19.

Please respond to the technical explanation I provided, and stop
referring to the functionality ** which is still there and works **
as being disabled.

The breakage is that devices that are happy to suspend with enabled
interrupts can no longer be suspended from userspace. Refusing to
suspend a single device on the basis that some other driver on the bus
may, potentially, at some point require some suspend code to be run with
disabled interrupts is not a sensible choice. Especially since I can't
actually find a single driver in the kernel tree that currently uses
this functionality.

I can't help it if that schedule.txt patch took until 2.6.19 to get
upstream; ISTR it was available before 2.6.18 shipped. Maybe patches
to that file should be accelerated, even into the stable series.

That would still not have provided anywhere near enough warning.

One of the missing steps in Linus' formulation there is that not all
interfaces are equivalent in terms of support guarantee. Bugs are
interfaces, for example, and sometimes folk wrongly depend on them
when they persist for a long time (like, cough, this one).

The existence of the power/state interface wasn't a bug - it was a
deliberate decision to add it. It's the only reason the
dpm_runtime_suspend() interface exists. It's perfectly reasonable to
refer to it as a flawed interface, or perhaps even a buggy one. But in
itself, it's clearly not a bug. And it's perfectly reasonable for
userland to depend on interfaces that are deliberately exposed by the
kernel.

In contrast, the /sys/devices/.../power/state API has never had many
users beyond developers trying to test their drivers (without taking
the whole system into a low power state, which probably didn't work
in any case), and has *always* been problematic. And the change you
object to doesn't "break" anything fundamental, either. Everything
still works.

It's used on every Ubuntu and Suse system, and the change means that
certain functionality no longer works - it's now impossible to prevent
my wireless hardware from drawing power when I'm not using it, for
example. If the WE power operations were deliberately disabled, then
that would also be a bug.

--
Matthew Garrett | mjg59@xxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • [PATCH] Documentation cleanup: trivial misspelling, punctuation, and grammar corrections.
    ... Different DMA engines may support different number of domains. ... +- API for paravirt ops for abstracting functionality for VMM folks. ... Read/Write attribute file that controls memory scrubbing. ... + Further information can be found in the interfaces section below for ...
    (Linux-Kernel)
  • Re: Part 2; COM issues
    ... with the functionality of the object, you would have no visibility into ... > client code..and actually I do not believe that the infrastructure ... infrastructure were encapsulated in its own subsystem, ... interfaces. ...
    (comp.object)
  • Re: Intel em receive hang and possible pr #72970
    ... Intel Pro 1000 MT dual-port copper server card ... the 2 fiber em interfaces seemed to stop receiving. ... from the network and move its processes to a backup machine. ... Does it seem that we are encountering that bug? ...
    (freebsd-net)
  • Intel em receive hang and possible pr #72970
    ... Intel Pro 1000 MT dual-port copper server card ... These machines receive multicast & tcp data on multiple interfaces and process it & record it to disk and then rebroadcast it on one interface. ... The first time this happened we opted to quickly disconnect the machine from the network and move its processes to a backup machine. ... Is that bug fixed in 6.1-RELEASE, or is there an easy patch to 6.0-RELEASE. ...
    (freebsd-net)
  • Re: Did I write a good (efficient) program?
    ... I don't about "industry" but I have always weighed 'maintainability' very, ... Each of them represents encapsulated basic functionality that simply doesn't ... just like atoms or bricks; ... It was this that led me to consider interfaces very carefully. ...
    (comp.lang.cobol)