From owner-freebsd-mobile@FreeBSD.ORG Mon Dec 6 17:36:22 2004 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64EE216A4CE for ; Mon, 6 Dec 2004 17:36:22 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B37943D48 for ; Mon, 6 Dec 2004 17:36:22 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 418EECC0B; Mon, 6 Dec 2004 12:36:21 -0500 (EST) Received: by canoe.dclg.ca (Postfix, from userid 101) id A56C26820; Mon, 6 Dec 2004 12:36:18 -0500 (EST) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16820.39058.626935.536607@canoe.dclg.ca> Date: Mon, 6 Dec 2004 12:36:18 -0500 To: Eric Anderson In-Reply-To: <41B07316.8060506@centtech.com> References: <20041202190737.163cd7af.karsten.rothemund@uni-rostock.de> <20041203094355.GC739@galadriel.bbk.hh.aegisnet.de> <41B05262.7060400@uni-rostock.de> <41B07316.8060506@centtech.com> X-Mailer: VM 7.17 under 21.5 (beta17) "chayote" (+CVS-20040321) XEmacs Lucid cc: Karsten Rothemund cc: freebsd-mobile@freebsd.org Subject: Re: Suspend-to-disk X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2004 17:36:22 -0000 I also left room for a suspend to disk partition on my D-800 ... although I've never seen it work in past attempts. It seems to me that an equally acceptable (and possibly better) strategy for FreeBSD would be a soft suspend to disk that is hardware agnostic. Linux seems to have done this. One way to implement this that has been discussed is to dump application memory to disk (possibly on the swap partition) ... some form of forced swapout (the opposite of the unswap). Then comes saving the kernel state. This is the somewhat more problematic thing ... since the running kernel has trouble saving itself. But we already have the "dump" process. Can the loader pick up on something that tells it to load the dump rather than the kernel? This may mean having an overly large swap partition, but this setup would preserve your environment across reboots ... and presumably make reboots quite quick. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================