From owner-freebsd-hackers Mon Jun 19 18: 2:44 2000 Delivered-To: freebsd-hackers@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 CA57637B8E5 for ; Mon, 19 Jun 2000 18:02:38 -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 LAA04363 for ; Tue, 20 Jun 2000 11:02:34 +1000 (EST) Received: (qmail 55498 invoked by uid 1000); 20 Jun 2000 01:02:32 -0000 From: "Andrew Reilly" Date: Tue, 20 Jun 2000 11:02:32 +1000 To: Mike Smith Cc: Andrew Reilly , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ACPI project progress report Message-ID: <20000620110232.B52825@gurney.reilly.home> References: <20000620101608.A38965@gurney.reilly.home> <200006200040.RAA10386@mass.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200006200040.RAA10386@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Mon, Jun 19, 2000 at 05:40:30PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote: > 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. Don't the normal TCP timeouts take care of existing connections? I doubt that a "server class" system will be going into suspend mode for any reason, but I would imagine that suspend/resume should look much like network outage for the clients of suspended servers. For the only place that I can see it mattering (laptops), I suspect that suspend/resume should be an X session manager and application level job, and the kernel should just shutdown and boot as normal. I know that there aren't too many X applications that do all of the session management things, but maybe that would change if suspend actions interacted with the popular desktops in the appropriate way. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message