On Thu, Jul 05, 2007 at 04:09:24PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 15:46, Matthew Garrett wrote:
> > I have a model for STD that avoids the need to freeze the entirity of
> > userspace, but I need to find some more time to flesh it out.
>
> You can just describe it, as far as I'm concerned. :-)
The basic model is that nobody's really described a use-case where we
actually care about restoring system state. What people want is to be
able to restore application state. So, arguably, what we want isn't to
save the entire kernel state and application state in one go because we
can reconstruct a huge amount of that afterwards.
This isn't too much of a problem. All we actually need to be able to do
is to atomically dump process state (which requires the freezer, but
doesn't require freezing the entire system), shut down, get the system
back into approximately the correct state (remount filesystems, start X,
whatever) and then restore the processes.
Now, obviously, there's actually quite a lot of complexity here that I'm
neatly eliding :) The biggest issue is restoring hardware state. We'd
require quite a different model to the existing one, but I think there
are arguments there for it being helpful anywy. Keeping state in the
midlevels rather than the low-level drivers would give us much more
ability to deal with hardware issues, and potentially allow the
replacement of faulty hardware without userspace caring (freeze your
mission-critical application, hotplug the network card, let the kernel
restore state and resume it)
There's other advantages to this. As long as the kernel hasn't changed
too much it would be possible to restore userspace across kernel
security upgrades. You end up saving less to disk so performance should
be better. Touching filesystems between suspend and resume doesn't
result in the entire world ending.
I've mocked up a basic implementation using cryopid, but it's somewhat
limited by the lack of support for sockets. I'd like to move more of the
smarts into the kernel (Hurray, checkpointing!) and then see how much
hardware support ends up horifically broken.
--
Matthew Garrett | [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
