Juanito
It's been said I was Zorros maniacal twin brother -- Juanito Peligros (1778)
On Mon, 26 Oct 1998, MOLNAR Ingo wrote:
>
> On Mon, 26 Oct 1998, Kuti Gabor wrote:
>
> > 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/
>
-
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/