Date: Tue, 20 Jun 2000 11:02:32 +1000 From: "Andrew Reilly" <areilly@nsw.bigpond.net.au> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Andrew Reilly <areilly@nsw.bigpond.net.au>, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ACPI project progress report Message-ID: <20000620110232.B52825@gurney.reilly.home> In-Reply-To: <200006200040.RAA10386@mass.osd.bsdi.com>; from msmith@FreeBSD.ORG on Mon, Jun 19, 2000 at 05:40:30PM -0700 References: <20000620101608.A38965@gurney.reilly.home> <200006200040.RAA10386@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000620110232.B52825>