|
| Swsusp |
When announcing SBUML on user-mode-linux-devel, one of the first questions to come up was its relationship with the swsusp project for hibernating Linux systems (http://swsusp.sourceforge.net/). This is a good question and until there is time to write a more complete answer, here is the quick response I posted back to the list:
From: Richard Potter
To: user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] demo of SBUML - swsusp functionality for UML
>>>From: BlaisorBlade
>>> Sorry, I've a question: how is this project related with swsusp?
The short answer is that SBUML does not use any code from swsusp and works today.
>>Should they do the same thing? Or different ones?
One answer is that swsusp was designed to save *one temporary*
snapshot of a notebook computer's state. In contrast, SBUML saves
*multiple persistent* snapshots of a UML's state. However, maybe this
is not such an interesting difference, since there must be an easy way
to have swsusp save its data to some location that will survive
multiple save and restore operations. (Does anybody know of a swsusp
implementation that will save multiple snapshots of a machine
including hard disks at various points in time?)
Another answer is that it is important for SBUML to restore the image
of the UML as exactly as possible, because it is meant to support
programming tools. For example, it should be possible to be in the
middle of doing kernel debugging, save a snapshot, and continue
debugging with confidence with the snapshot resumed into another UML,
possibly on another physical host machine. (Unfortunately, the
current version of SBUML does not save the connection to GDB, so this
demo is not quite ready...however it will be in future releases.)
As far as I can tell, swsusp is intended for continuing user sessions,
so it is OK for swsusp to use techniques that might change the kernel
state and other hidden state as long as the changes are transparent
to end users.
--Richard
|
|
|
|
