[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200612191919.36813.david-b@pacbell.net>
Date: Tue, 19 Dec 2006 19:19:36 -0800
From: David Brownell <david-b@...bell.net>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: linux-kernel@...r.kernel.org, gregkh@...e.de
Subject: Re: Changes to PM layer break userspace
On Tuesday 19 December 2006 4:09 pm, Matthew Garrett wrote:
> On Tue, Dec 19, 2006 at 03:36:28PM -0800, David Brownell wrote:
> > On Tuesday 19 December 2006 2:57 pm, Matthew Garrett wrote:
> > > The fact that something is scheduled to be removed in July 2007 does
> > > *not* mean it's acceptable to break it in 2006. We need to find a way to
> > > fix this functionality in the meantime.
> >
> > The disconnect here is analagous to: I tell you the alleged perpetual
> > motion machine never worked, and can't ever work; and you push back and
> > say that you need a perpetual motion machine that works, NOW please,
> > because you need something that pushes those widgets around. (There are
> > better ways to push widgets than side effects of a broken machine...)
>
> But it *did* work.
Having been on the other side ... I can testify that if you
think it actually worked, it's because you're ignoring all
the nasty failure modes.
> > I'd not be keen on reverting Linus' patch [1] myself, even though few
> > drivers have started to use that mechanism yet; that would be a step
> > backwards, and would perpetuate users of that broken sysfs file.
>
> I'm sorry, which bit of "Don't break userspace API without adequate
> prior warning and with a workable replacement" is difficult to
> understand?
What part of "it was already broken" do YOU not understand? The
whole notion is unsustainable. It doesn't work cross-platform, or
for multiple bus types. It confuses system-wide suspend mechanisms
with runtime mechanisms. It breaks guaranteed parent/child ordering
of suspend/resume calls. (And more...)
Let us know when you get tired of whining and want to move on to
getting a real solution to the set of problems here. I've pointed
out that reverting Linus' patch would be one option to get your
short term issue rsolved ... that would remove a capability from
PCI drivers, but you could then use that deprecated mechanism.
I've also pointed out that you could start working towards a real
long term solution.
Do you have an alternate solution?
- 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