Date: Mon, 22 Aug 2016 22:14:05 -0700 From: Conrad Meyer <cem@freebsd.org> To: Eric McCorkle <eric@metricspace.net> Cc: hackers@freebsd.org Subject: Re: Info about suspend-to-disk Message-ID: <CAG6CVpXxsbOQqOiytcrFSp486Cdzu9ny8HQmG=nzq_r-fhce0Q@mail.gmail.com> In-Reply-To: <141b1050-8fb5-e8c7-0e0f-50607f2f28b9@metricspace.net> References: <141b1050-8fb5-e8c7-0e0f-50607f2f28b9@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Eric, On Mon, Aug 22, 2016 at 8:41 PM, Eric McCorkle <eric@metricspace.net> wrote: > Hi everyone, > > I'm gathering information in preparation for possibly working on > suspend-to-disk functionality. I have a fairly good idea of what it > would take and one way to attack it. The overall plan would look > something like this: > > * Use dump functionality to write an entire OS image out to disk. As > this is a voluntary dump, it should be possible to go through the FS > interface to produce a regular file. > > * Modify boot1 to check for saved images. Load and resume if one exists. That sort of thing should probably go in loader, not boot1. (boot0-2 are just the MBR boot block(s), as I understand it; loader is the last pre-OS stage and where most features live.) > * Presumably there would need to be some new device methods added to do > saving/reinitialization of devices. Probably similar problems to kexec/kboot. (That was a major roadblock for kexec efforts, I believe.) I think getting this right will be the really challenging part. > The major open questions for me are the following: > > * Is there/has there been significant work in this direction? > > * Is there perhaps a better strategy? > > * Do the codepaths currently exist to allow dump functionality to write > to a regular file in the case of a voluntary dump, or would this need to > be added? That would have to be added. You could maybe register a file dumperinfo (as long as you're careful to prevent its use on panic-during-suspend), but nothing does this yet. > * What would be the most sensible default behavior for device > hibernate/unhibernate methods? > > * Any other significant issues Undoubtedly something will come up :-). Best, Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXxsbOQqOiytcrFSp486Cdzu9ny8HQmG=nzq_r-fhce0Q>