Skip site navigation (1)Skip section navigation (2)
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-hackers" 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>