Resuming from a crashdump

[Matthew Dillon]

:...
:I'm not interested in resuming after a real crash. The idea is
:to get suspend/resume functionality without hardware support.
:
:So there would be no panic, but the system would be brought to
:a halt and the memory dumped.
:
:> Also the devices wouldn't be in the state they had been in at
:> the time of the panic, so if you could get as far as the
:> reloaded kernel actualy doing anything, you'd either crash again
:> or risk corrupting things horribly.
:
:That's why they would have to be reinitialized.
:
:-- 
:Christian Laursen

    It is not really doable to try to restore a kernel core dump.  The
    problem is that once the kernel has booted to the point where it can
    check the core, it's memory will already contain hundreds if not 
    thousands of data structures related to booting and you can't just 
    overwrite them with the core image and hope that things will still work.

    The phrase 'blown to smitherines' would take on new meaning :-)

    For example, it would be virtually impossible to figure out which
    portions of the image need to be thrown away (e.g. network
    connections, device driver related allocations that have already been
    done), which portions are related to device side effects and need to
    be reintegrated, which portions are related to kernel stack contexts
    whos memory may already be used by the boot sequence, and so forth.

    It is far easier to restore a process's VM image because the image
    is mostly self contained, and the restoration occurs in a context outside
    of the image.  The kernel doesn't work that way... there are a ton of
    side effects related to device state and there is no 'outside of context'
    way to do the restore.  There is no convenient 'vmspace' structure for
    the kernel like there is for a process.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>