You forgot the most important thing : these two kernels will run onA similar way as "kdump" did. Just putting a backup kernel into the memory and receiving keepalives by primary kernel. In normal conditions, backup kernel just will sit in its place, will monitor the status of primary kernel (alive or crashed) and will do nothing else more. So, no scheduling is required.
the same machine. I'm not even considering how you intend to schedule
them. However, when a kernel crashes, it's often because of a hard
error : bug in a driver, memory corruption, etc... You cannot sanelyHardware related issues are exceptions. If there could be a journal; maybe, it could be possible to recover sanely where the primary left. Of course, it's clear that this system will not work for all the scenarios (like bad hardware etc.).
recover from that. If the driver which crashed started to initiate a
multi-word command to the device, in a lot of situations you'll need
a reset to restore it in a known state. Memory corruption is even
worse, as you cannot even trust the backup kernel.
I'm currently using a backup kernel in our products, and do it withYep, it's very simple way. But the problem is that, as you mentioned, watchdog is not supported on all the hardwares. If possible to implement, it will be platform/hardware independent system.
the boot loader. Some BIOSes allow you to start a watchdog timer on
boot. Grub tries to load the first image, otherwise the second one.
If either image crashes during boot, the hardware watchdog triggers
and the machine reboots to the other image. That's extremely reliable,
and relatively simple.
And using this method, you don't have any compatibility problems between
your primary and secondary kernels.