HardwareCheckpointable

From Linux Checkpoint / Restart Wiki
(Difference between revisions)
Jump to: navigation, search
(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.

Personal tools