From owner-freebsd-hackers Mon Jun 19 17:35:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 076A537B708; Mon, 19 Jun 2000 17:35:43 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id RAA10386; Mon, 19 Jun 2000 17:40:30 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006200040.RAA10386@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Andrew Reilly" Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ACPI project progress report In-reply-to: Your message of "Tue, 20 Jun 2000 10:16:08 +1000." <20000620101608.A38965@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jun 2000 17:40:30 -0700 From: Mike Smith Sender: owner-freebsd-hackers@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? (*) 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