Message-Id: <200612191959.43019.david-b@pacbell.net>
Date:	Tue, 19 Dec 2006 19:59:42 -0800
From:	David Brownell <david-b@...bell.net>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, gregkh@...e.de
Subject: Re: Changes to PM layer break userspace

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists