Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Jun 2000 17:40:30 -0700
From:      Mike Smith <msmith@freebsd.org>
To:        "Andrew Reilly" <areilly@nsw.bigpond.net.au>
Cc:        freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject:   Re: ACPI project progress report 
Message-ID:  <200006200040.RAA10386@mass.osd.bsdi.com>
In-Reply-To: Your message of "Tue, 20 Jun 2000 10:16:08 %2B1000." <20000620101608.A38965@gurney.reilly.home> 

next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote:
> > In message <20000620085531.A38839@gurney.reilly.home> "Andrew Reilly" writes:
> > : That sounds way too hard.  Why not restrict suspend activity to
> > : user-level processes and bring the kernel/drivers back up through
> > : a regular boot process?  At least that way the hardware and drivers
> > : will know what they are all up to, even if some of it has changed
> > : in the mean time.
> > 
> > Takes too long...  That's shutdown, not S4.
> 
> Yes.  But what is the difference, really?  As far as the
> hardware is concerned, it's being booted.  If that process can
> be sped up by using the "S4" mechanisms, why can't they be
> applied to a regular boot process too?  [I'm thinking about a
> kernel equivelant of the "clean shutdown" flag on file systems.]
> 
> Fundamentally, is there no way to get the kernel and drivers to
> go through a full boot phase in a small fraction of the time
> that it takes to repopulate 64M of RAM from disk? (*)

The real issue here is persistent system state across the S4 suspend; ie.
leaving applications open, etc.  IMO this isn't really something worth a 
lot of effort to us, and it has a lot of additional complications for a 
"server-class" operating system in that you have to worry about network 
connections from other systems, not just _to_ other systems.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006200040.RAA10386>