Difference between revisions of "What's bad with V1 images"

From CRIU
Jump to: navigation, search
Line 11: Line 11:
 
* clear_thread_info in per-arch members
 
* clear_thread_info in per-arch members
 
* it would be great to unify inotify and fanotify images into one fsnotify file
 
* it would be great to unify inotify and fanotify images into one fsnotify file
 +
* currently we write checkpoint files with '''*.img''' extension, which might be confusing since this extension is a way overloaded by meaning and quite widespreaded, thus it might be worth to change extension to '''*.criu'''

Revision as of 20:00, 6 March 2013

Current images format is great, but sometimes we find problems with it. This page collects all we don't like about them and would like to change some time in the future (once we change this, image format version will be changed as well).

  • vma.proto vma_entry->fd is unused
  • ipc-msg.proto ipc_msg/ipc_msg_entry names mess
  • sk-packet.proto vs packet-sock.proto names mess (all sockets .proto files are sk-<something>)
  • core.proto blk_sigset for master thread is on task_core_entry, but should be in respective thread_core_entry
  • pstree.proto: sid and pgid should NOT be there, but in core image
  • core.proto -- padding for fpu is not used
  • what to do with absent image files? Backward compatibility requires we still restore, common sense -- abort. Flooding inventory with every single new image doesn't sound that great.
  • core.proto -- unused (though optional) ids field
  • clear_thread_info in per-arch members
  • it would be great to unify inotify and fanotify images into one fsnotify file
  • currently we write checkpoint files with *.img extension, which might be confusing since this extension is a way overloaded by meaning and quite widespreaded, thus it might be worth to change extension to *.criu