[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0707201820050.5241-100000@iolanthe.rowland.org>
Date: Fri, 20 Jul 2007 18:25:16 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Oliver Neukum <oliver@...kum.org>
cc: Milton Miller <miltonm@....com>, Ying Huang <ying.huang@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, David Lang <david@...g.hm>,
linux-pm <linux-pm@...ts.linux-foundation.org>,
Jeremy Maitin-Shepard <jbms@....edu>
Subject: Re: [linux-pm] Re: Hibernation considerations
On Fri, 20 Jul 2007, Oliver Neukum wrote:
> > We already have a pre-suspend notification available for drivers that
> > need to allocate large amounts of memory.
>
> Is that facility fine grained enough?
It's a notifier chain that gets called at several points during the
suspend transition. One of those points is right at the start, while
userspace is still running and reasonably large amounts of memory can
be allocated.
Is it fine-grained enough? I don't know -- hard to tell, since nothing
much is using it yet.
> > You are correct about the need to delay/stop device addition. I don't
> > know how this can be done in general; each code path calling
> > device_add() may have to be treated individually.
>
> What about the old API?
What old API do you mean?
> Do we have to block module loading?
No. Registering new drivers is okay, registering new devices is bad.
Of course, some modules do want to register a new device in their init
method. I don't know what we should do about them. Force the
registration to fail, I suppose. How often will people suspend while a
module is loading?
> What happens if a scsi error handler is woken? If it cannot be woken,
> how are errors handled?
Why should the error handler wake up? There isn't supposed to be any
I/O going on, hence no errors to handle.
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