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/
