From owner-acpi-jp@jp.freebsd.org  Tue Jun 20 09:16:47 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id JAA45785;
	Tue, 20 Jun 2000 09:16:47 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from sr14.nsw-remote.bigpond.net.au ([24.192.3.29])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id JAA45776
	for <acpi-jp@jp.freebsd.org>; Tue, 20 Jun 2000 09:16:45 +0900 (JST)
	(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 KAA27261
	for <acpi-jp@jp.freebsd.org>; Tue, 20 Jun 2000 10:16:10 +1000 (EST)
Received: (qmail 49345 invoked by uid 1000); 20 Jun 2000 00:16:08 -0000
From: "Andrew Reilly" <areilly@nsw.bigpond.net.au>
Date: Tue, 20 Jun 2000 10:16:08 +1000
To: Warner Losh <imp@village.org>
Cc: Andrew Reilly <areilly@nsw.bigpond.net.au>,
        Poul-Henning Kamp <phk@critter.freebsd.dk>,
        Mitsuru IWASAKI <iwasaki@jp.freebsd.org>,
        bfischer@Techfak.Uni-Bielefeld.DE, acpi-jp@jp.freebsd.org,
        dcs@newsguy.com, freebsd-current@FreeBSD.ORG,
        freebsd-hackers@FreeBSD.ORG
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
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 425
Subject: [acpi-jp 425] Re: ACPI project progress report
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: areilly@nsw.bigpond.net.au

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
