Resuming from a crashdump

[ctodd at chrismiller.com]

>     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.

Well booting the kernel generally takes little time, but if all the
processes could be restored this would be a step in the right direction.
As John said, restoring the state of some programs will have to rely on
the program, but perhaps this could lead to an API of some sort that would
make this less painful on the program author. Eventually most programs
would support this over time.

So what would it take to get the system to boot the kernel, then rebuild
the processes from VM?

Chris