Quoting Alexey Dobriyan (adobriyan@xxxxxxxxx): > On Mon, Apr 13, 2009 at 04:47:01PM -0500, Serge E. Hallyn wrote: > > Quoting Alexey Dobriyan (adobriyan@xxxxxxxxx): > > > > Hi Alexey, > > > > as far as I can see, the main differences between this patch and the > > equivalent in Oren's tree are: > > > > 1. kernel auto-selects container init to freeze > > Note, auto-select part was dropped, userspace is required to pass pid of > container init exactly. This was done to keep semantic of checkpoint(2) > small and extendable. sys_checkpoint() in this patch still finds the child_reaper of the passed-in pid, doesn't it? Or are you saying that a later patch in this set removes that? > > 2. kernel freezes tasks > > 3. no objhash taking references > > That's because none needed. Right while I have opinions on some things in this list, I didn't mean to imply positions on these items. My question was: are there are differences you want to call out? > > 4. no hbuf > > hbuf is an optimization to not allocate/free memory for every image. > For a start it's unnecessary complication, I just kzalloc/dump/kfree. > > > 5. always require CAP_SYS_ADMIN > > > > Are there other differences which you would consider meaningful? Which > > do you consider the most important? > > > > Also, since Dave introduced the fops->checkpoint(), we (or at least I) > > have been struck by the ugly assymetry with checkpoint() being in fops, > > and restart() not. Do you have an idea for fixing that? > > Module can legally support C/R for its files. > In the end it most certainly will end up with module registering restart Which module? The module defining a filesystem? In that case I'm just not clear on how the restart code will know which fs's file_operations to use to pick a fops->restart() fn. > hook for file type N. > > Or module registering hook to restart object type N. > > This is for discussion. Ok, it's just something I've wondered (with both patchsets). thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
