[lkml]   [1998]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: context_switching&machine_suspend()

    If you solve the problems to do this, it would require very minor patches
    to upgrade a kernel "silently" in place with only a 1 or two second
    "suspension" visible to the programs running.


    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
    > Please read the FAQ at

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:45    [W:0.028 / U:17.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site