On 03/03/2009 05:29 AM, David Newall wrote:It sounds like you want everything to just continue running. I don'tYes, exactly. Backup kernel will take control when a crush occured without need a reboot or halt.
see how that can be done. All of those in-kernel tables and structuresYes, that's right and it's the first thing needed to overcome. Maybe, it could be implemented like this :
would need to be migrated, and it follows, because there was a crash,
that any of them might have been corrupted. Worse, you want this to
save you when you try running a new kernel which crashes, and being a
new kernel, it follows that any of those structures could be different;
it might not be possible to create equivalent structures for different
kernel versions.
- Primary kernel could be 2.6.x or 2.6.x.y (2.6.28 or 2.6.28.1)
- Backup kernel could be one of these .y fix releases only: Like 2.6.28.5
So; when they're from the same version, it will prevent kernel API and structure changes.
For resuming by backup kernel: The primary kernel could write a journal about the needed things for backup to resume. Like process IDs, memory and process situations etc. The same manner as the Journalled File Systems did (they write a journal what they did to recover/resume at crash/disaster time).