[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0804131916420.3060-100000@netrider.rowland.org>
Date: Sun, 13 Apr 2008 19:23:23 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Nigel Cunningham <ncunningham@...a.org.au>
cc: benh@...nel.crashing.org, "Rafael J. Wysocki" <rjw@...k.pl>,
Greg KH <greg@...ah.com>,
pm list <linux-pm@...ts.linux-foundation.org>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Len Brown <lenb@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Alexey Starikovskiy <astarikovskiy@...e.de>,
David Brownell <david-b@...bell.net>,
Pavel Machek <pavel@....cz>, Oliver Neukum <oliver@...kum.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/3] PM: Introduce new top level suspend and hibernation
callbacks (rev. 8)
On Mon, 14 Apr 2008, Nigel Cunningham wrote:
> > The ability for prepare() callbacks to sync with userland,
> > request_firmware, etc... is an important feature that's been needed for
> > some time imho.
> >
> > Ben.
>
> I agree. These calls have already been changing far too often in
> mainline. I know it's all been necessary but please, can we try to make
> one set of changes and just get it right this time?
In practical terms, it will be easier to keep the freezer where it is
for now. This is because prepare() requires drivers to change their
behavior; they aren't allowed to register new children any more.
But if userspace isn't frozen then user programs can interact with
drivers in a way that does cause new children to be created. For
example this happens in USB, where opening an audio device and
selecting its bitrate causes a new set of endpoints to be realized,
along with their representations in sysfs.
Thus, in addition to making all the interface changes implied by the
new callbacks, drivers would also have to change the way they interact
with userspace. Yes, this will have to be done eventually in any case,
as the freezer goes away -- but it shouldn't have to be done right now.
Alan Stern
--
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