[Devel] Re: [PATCH] c/r: Add UTS support (v4)

Serge E. Hallyn serue at us.ibm.com
Fri Mar 20 11:10:43 PDT 2009


Quoting Oren Laadan (orenl at cs.columbia.edu):
> What got me confused was that you loop over all tasks, which is not
> needed because was assume they all share the name nsproxy; And in
> restart, you unshare() many times by the same task, so all but the
> last unshare() are useless.  In other words, I wonder what is the
> need for that loop over all processes.
> 
> Here is a suggestion for a simple change that is likely to be a step
> towards more generic solution in the future:
> 
> The nsprox is a property of a task, and it is (possibly) shared. We
> can put the data either on the pids_arr or on the cr_hdr_task itself.
> For simplicity (and to work with your scheme) let's assume the former.
> 
> We can extend the pids_arr to have a ns_objref field, that will hold
> the objref of the nxproxy. Of course, now, all pids_arr will have the
> same objref, or else ...  This data will follow the pids_arr data in
> the image.
> 
> During checkpoint, we read the pids_arr from the image, and then for
> each objref of an nsproxy that is seen for the first time, we read
> the state of that nsproxy and restore a new one. (In our simple case,
> there will always be exactly one).

The nsproxy is not the right thing to record.  Rather, it
should record a bitmap  of namespaces which are to be private
from the parent task.  Then for each private ns, an optional
section with configuration info.

(maybe that is waht you meant by 'recording the nsproxy')

-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list