From owner-freebsd-current Mon Jun 19 17:16:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id B3A0137B880 for ; Mon, 19 Jun 2000 17:16:15 -0700 (PDT) (envelope-from areilly@nsw.bigpond.net.au) Received: from areilly.bpc-users.org (CPE-144-132-171-71.nsw.bigpond.net.au [144.132.171.71]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id KAA27252 for ; Tue, 20 Jun 2000 10:16:09 +1000 (EST) Received: (qmail 49345 invoked by uid 1000); 20 Jun 2000 00:16:08 -0000 From: "Andrew Reilly" Date: Tue, 20 Jun 2000 10:16:08 +1000 To: Warner Losh Cc: Andrew Reilly , Poul-Henning Kamp , Mitsuru IWASAKI , bfischer@Techfak.Uni-Bielefeld.DE, acpi-jp@jp.freebsd.org, dcs@newsguy.com, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ACPI project progress report Message-ID: <20000620101608.A38965@gurney.reilly.home> References: <20000620085531.A38839@gurney.reilly.home> <200006191630.KAA60652@harmony.village.org> <45525.961432574@critter.freebsd.dk> <20000620085531.A38839@gurney.reilly.home> <200006192301.RAA63461@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006192301.RAA63461@harmony.village.org>; from imp@village.org on Mon, Jun 19, 2000 at 05:01:46PM -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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? (*) I'm concerned about trying to take short-cuts with booting, because I've seen both the Toshiba laptop that I'm using now, and my mother's HP desktop system hang horribly hard when they should have been coming out of suspend. (Both W'98.) I like the idea that my laptop will save power by shutting down after a while, but I don't want to get into trouble if I forget whether I was docked or not, or whether the floppy was plugged in or not, when next I turn it on. (*) Speaking of which: why are we considering doing process dumps into a _different_ swap-ish partition, instead of just ensuring that all processes are sleeping in the normal swap partition? If that was done, then they would just page themselves back in as needed, on wake-up. Sorry for blathering. This is just really interesting stuff. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message