Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): > > > Dan Smith wrote: > > SH> Well it forces restart to go through the established userspace > > SH> API's when creating resources (in this case, tasks and namespaces) > > SH> which means any existing security guarantees are leveraged. > > > > That's a very valid point. However, it still seems unbalanced to make > > checkpoint a completely in-kernel process and restart an odd mix of > > the two with potentially more confusing semantics and requirements. > > > > There are other reasons to allow restart to be not fully symmetric > with respect to checkpoint. For example, if you have a smart(er) user > space application that wants to provide the restart some of the resources > pre-constructed, allowing much flexibility (already requested by people) > for the restart provdure (E.g., when doing distributed checkpoint, or > when restarting a special device whose). > > See my post: > https://lists.linux-foundation.org/pipermail/containers/2009-March/016234.html (Note that in Dan's next version, he did move unshare into userspace) -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
