Difference between revisions of "History"

From CRIU
Jump to: navigation, search
(Created page with "* Pavel sent POC in LKML. From: Pavel Emelyanov Subject: [RFC][PATCH 0/7 + tools] Checkpoint/restore mostly in the userspace Date: Fri, 15 Jul 2011 17:45:10 +0400 * Jonathan ...")
 
Line 28: Line 28:
 
       eventually comes to tears and the project as a whole fails, it should                                                               
 
       eventually comes to tears and the project as a whole fails, it should                                                               
 
       be a simple matter to go through and delete all trace of it.
 
       be a simple matter to go through and delete all trace of it.
 +
* Andrew Morton starts to doubt in CRIU [https://lkml.org/lkml/2012/2/14/384 "link"]
 +
Thus far our (my) approach has been to trickle the c/r support code
 +
into mainline as it is developed.  Under the assumption that the end
 +
result will be acceptable and useful kernel code.
 +
 +
I'm afraid that I'm losing confidence in that approach.  We have this
 +
patchset, we have Stanislav's "IPC: checkpoint/restore in userspace
 +
enhancements" (which apparently needs to get more complex to support
 +
LSM context c/r).  I simply *don't know* what additional patchsets are
 +
expected.  And from what you told me it sounds like networking support
 +
is at a very early stage and I fear for what the end result of that
 +
will look like.
 +
 +
So I don't feel that I can continue feeding these things into mainline
 +
until someone can convince me that we won't have a nasty mess (and/or
 +
an unsufficiently useful feature) at the end of the project.

Revision as of 09:05, 5 March 2012

  • Pavel sent POC in LKML.
From: Pavel Emelyanov
Subject: [RFC][PATCH 0/7 + tools] Checkpoint/restore mostly in the userspace
Date: Fri, 15 Jul 2011 17:45:10 +0400
  • Linus merged a first wave of patches, adding his thoughts about this (commit 0994695)
    - checkpoint/restart feature work.                                                                                                    
                                                                                                                                          
      A note on this: this is a project by various mad Russians to perform                                                                
      c/r mainly from userspace, with various oddball helper code added                                                                   
      into the kernel where the need is demonstrated.                                                                                     
                                                                                                                                          
      So rather than some large central lump of code, what we have is                                                                     
      little bits and pieces popping up in various places which either                                                                    
      expose something new or which permit something which is normally                                                                    
      kernel-private to be modified.                                                                                                      
                                                                                                                                          
      The overall project is an ongoing thing.  I've judged that the size                                                                 
      and scope of the thing means that we're more likely to be successful                                                                
      with it if we integrate the support into mainline piecemeal rather                                                                  
      than allowing it all to develop out-of-tree.                                                                                        
                                                                                                                                          
      However I'm less confident than the developers that it will all                                                                     
      eventually work! So what I'm asking them to do is to wrap each piece                                                                
      of new code inside CONFIG_CHECKPOINT_RESTORE.  So if it all                                                                         
      eventually comes to tears and the project as a whole fails, it should                                                               
      be a simple matter to go through and delete all trace of it.
  • Andrew Morton starts to doubt in CRIU "link"
Thus far our (my) approach has been to trickle the c/r support code
into mainline as it is developed.  Under the assumption that the end
result will be acceptable and useful kernel code.

I'm afraid that I'm losing confidence in that approach.  We have this
patchset, we have Stanislav's "IPC: checkpoint/restore in userspace
enhancements" (which apparently needs to get more complex to support
LSM context c/r).  I simply *don't know* what additional patchsets are
expected.  And from what you told me it sounds like networking support
is at a very early stage and I fear for what the end result of that
will look like.

So I don't feel that I can continue feeding these things into mainline
until someone can convince me that we won't have a nasty mess (and/or
an unsufficiently useful feature) at the end of the project.