Info about suspend-to-disk

[Allan Jude]

On 2016-08-23 01:14, Conrad Meyer wrote:
> Hi Eric,
> 
> On Mon, Aug 22, 2016 at 8:41 PM, Eric McCorkle <eric at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 


-- 
Allan Jude