> I recently read a discusiion about a freeze/thaw plugin.
> someone stated that the biggest challenge would be to
> save/restore note the cpu state, but all external plugins�
> state(maybe im wrong on this. it was something with "all external
> I/O devices", but those are all in the bochs-plugin, right?).
> IIRC the plugin API has no save/restore interface.
That would be me.
The comment that saving IO devices is the hard part was more or less
a guess; I'm not really qualified for more. But from what I can
tell, getting the CPU state is pretty easy -- all the hard parts
(noteably the hidden parts of the descriptors) we have virtualized.
Everything we don't have virtualized we can steal from the task-switch
code of the kernel (any kernel), pretty much.
I rather like your idea of adding save/restore APIs for plugins; that
would indeed make it easy.
How's this API:
void *plugin_saveyourself(size_t *len);
int plugin_init (plugin_t *plugin, int argc, char *argv[], void *data, size_t len);
Where SaveYourself should return a pointer to arbitrary data to be
stored, and sets len to the length of that data. It is the plugin's
responsiblity to allocate memory, which will be leaked (we're about
to exit when this is called anyway, and this avoids the "which free()"
question).
The last two parameters on the plugin_init will be zero if not
restoring from a freeze. The plugin should check both that len
is not zero and that the pointer isn't NULL, however.
How does this sound? It would require freeze/thaw in core user, but
that shouldn't be too much of a problem.
I think we should make it simply undefined to restore plugin state
when the options for that plugin have changed. That should keep the
restore code from being too hairy. I think most things would only
have to save their global vars and literaly restore them.
-=- James Mastros
