Date: Tue, 23 Aug 2016 01:23:06 -0400 From: Allan Jude <allanjude@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: Info about suspend-to-disk Message-ID: <7a9fcbee-c849-d2b7-6608-732c29fab539@freebsd.org> In-Reply-To: <CAG6CVpXxsbOQqOiytcrFSp486Cdzu9ny8HQmG=nzq_r-fhce0Q@mail.gmail.com> References: <141b1050-8fb5-e8c7-0e0f-50607f2f28b9@metricspace.net> <CAG6CVpXxsbOQqOiytcrFSp486Cdzu9ny8HQmG=nzq_r-fhce0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-08-23 01:14, Conrad Meyer wrote: > 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.) > * boot0 (512b) is the MBR/pMBR * boot1 (512b) is the VBR (loads and executes boot2) * boot2 (15kb for UFS+MBR, up to 512kb for GPT, 3.5mb of ZFS) is the first thing that actually understands file systems. This reads the loader from the file system * loader (boot3) But I agree, I don't think you'll need to make it any earlier than the loader to do a resume from suspend-to-disk. It can reload the in-memory image, and then start it executing again. >> * 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 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Allan Jude
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7a9fcbee-c849-d2b7-6608-732c29fab539>