HardwareCheckpointable
From Linux Checkpoint / Restart Wiki
(Difference between revisions)
(Created page with '1. Checkpoint of a task with a unsupported device mmap()ed will be refused because the vma type won't support checkpoint. 2. Checkpoint of any task with a unsupported /dev/foo f…') |
(Add link to uncheckpointable) |
||
| Line 1: | Line 1: | ||
1. Checkpoint of a task with a unsupported device mmap()ed will be refused because the vma type won't support checkpoint. | 1. Checkpoint of a task with a unsupported device mmap()ed will be refused because the vma type won't support checkpoint. | ||
| − | 2. Checkpoint of any task with a unsupported /dev/foo file open will be refused because the file won't have a valid ->checkpoint() function. | + | 2. Checkpoint of any task with a unsupported /dev/foo file open will be refused because the file won't have a [[UncheckpointableFilesystems|valid ->checkpoint() function]]. |
However, if an application has made some changes to hardware, then we do not have a generic way of | However, if an application has made some changes to hardware, then we do not have a generic way of | ||
ensuring the continuity of that state after restart. It is arguable whether doing so would be a good | ensuring the continuity of that state after restart. It is arguable whether doing so would be a good | ||
thing. | thing. | ||
Latest revision as of 17:15, 21 December 2009
1. Checkpoint of a task with a unsupported device mmap()ed will be refused because the vma type won't support checkpoint.
2. Checkpoint of any task with a unsupported /dev/foo file open will be refused because the file won't have a valid ->checkpoint() function.
However, if an application has made some changes to hardware, then we do not have a generic way of ensuring the continuity of that state after restart. It is arguable whether doing so would be a good thing.
