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>