> I'd like work on a new project. Its main goal would be that [preferably]
> all of the state of the machine would be saved on disk when pressing a
> magic sysrq key and this could be restored later [e.g. one day later].
hm, another tough problem is how to restore hardware state. Say you have a
video card with write-only registers. (but on the bright side, this should
be rather seldom, so it would work if you'd extend _your_ device drivers
to handle suspension, then extend the number of 'supported' drivers
slowly, as the architecture stabilizes)
> So I'll have to save all kernel structures. Since the structures are
> referenced by pointers the machine_restore() function should load all data
> to the psychical memory location as it was by saving. Of course for
> compatibility there will be register/unregister functions that every layer
> that needs to save some data could register its save function. I've got a
> relatively clean image of that.
you could just save the whole physical memory image without caring about
data structures. Maybe define some trampoline area that serves as a 'work
area' to do this 'switchover'. Explicitly registering/unregistering data
structures increases the comlpexity of the feature _alot_ i think. It's
enough fun already to do the hardware state stuff ...
> The problem right now is that I don't know anything about context
> swichting.
> I mean.. e.g. what happens when a process calls sleep_on or its time slice
> is over? Both cases schedule() is called. But.. since it will return
> sometime a stack is have to be managed by the processor.. It's all clean
> by a single threaded program of course but what happens here?
> Is the individual stacks for all processes or so? How will I be able to
> save them? I'd like to make this platform independent of course.
there are lots of 'chicken and egg' problems here. You need a working
kernel to do the IO to load a saved kernel. The switchover probably has to
involve some assembly functions too, to jump from the trampoline area into
a (pre-defined) entry point of the saved kernel. The problem is very
analogous to 'booting', so one possible solution could be to make such a
saved image bootable. (the kernel then would do the restore itself after
booting the kernel code) Thus you could do the switchover via a reboot.
(the reboot itself is not a problem, as you lose the original kernel
anyway, so it's not a problem to do a small reboot, the kernel will load a
possibly hundreds of megabytes memory image anyway)
also there are other problems like TCP connections to the outside world,
and disk contents. (what if the disk got modified since the last time that
image was booted and the image has a disk cache that is out-of-date). What
about the system date, is it going to be 'saved' too? So it's a _very_
difficult problem. Some people argue this should be done in user-space,
just like Condor does. (but doing it in the kernel is indeed more sexy).
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/