On Tuesday 19 December 2006 4:25 pm, Matthew Garrett wrote: > On Tue, Dec 19, 2006 at 01:34:49PM -0800, David Brownell wrote: > > > Documentation/feature-removal-schedule.txt has warned about this since > > August, and the PM list has discussed how broken that model is numerous > > times over the past several years. (I'm pretty sure that discussion has > > leaked out to LKML on occasion.) It shouldn't be news today. > > 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. > 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 fact that PCI exposes a mechanism that conflicts with that is a separate issue. Whining does not help. 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. > 3) "The whole _point_ of a kernel is to act as a abstraction layer and > resource management between user programs and hardware/outside world. > That's why kernels _exist_. Breaking user-land API's is thus by > definition something totally idiotic. > > If you need to break something, you create a new interface, and try to > translate between the two, and maybe you deprecate the old one so that > it can be removed once it's not in use any more. If you can't see that > this is how a kernel should work, you're missing the point of having a > kernel in the first place." > > Linus, http://lkml.org/lkml/2006/10/4/327 So I'm amused that the problem you refer to is the direct consequence of Linus' patch to add the suspend_late()/resume_early() mechanism into the PCI driver framework. (Again, see the technical explanation; and please try to have a technical discussion, not a flamefest.) 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). His comment was specifically about breaking a widely used API that many people have been relying on since, oh, about 1996, and had been well proven in that time. And the change was a "system doesn't work" level change. 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. In terms of any reasonable expectations about support, those two changes aren't comparable. - Dave - 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/
