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 | [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
