From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cedric Le Goater Subject: Re: [PATCH] An attempt to have an unlimitedly extendable sys_clone Date: Tue, 15 Jan 2008 16:56:39 +0100 Message-ID: <478CD7B7.4020409@fr.ibm.com> References: <478CAC32.4080809@openvz.org> <478CCE81.5090605@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <478CCE81.5090605-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Oren Laadan Cc: Linux Containers , Pavel Emelyanov List-Id: containers.vger.kernel.org Oren Laadan wrote: > > Pavel Emelyanov wrote: >> We have one bit in the clone_flags left, so we won't be >> able to create more namespaces after we make it busy. >> Besides, for checkpoint/restart jobs we might want to >> create tasks with pre-defined pids (virtual of course). >> What else might be required from clone() - nobody knows. >> >> This is an attempt to create a extendable API for clone. >> >> I use the last bit in the clone_flags for CLONE_NEWCLONE. > > how about "CLONE_EXTEND" ? > >> When set it will denote that the child_tidptr is not a >> pointer on the tid storage, but the pointer on the struct >> long_clone_struct which currently looks like this: >> >> struct long_clone_arg { >> int size; >> }; > > how about "ext_clone_arg" ? > > (both suggestion make the use more explicit and are more > consistent with each other; but definitely a nit ...) yeah I agree. The naming can be improved but let's just wait for the patch to be sent on lkml@. I'm sure we will have plenty of feedback. however, the last clone flag name should be consistent with the structure name. CLONE_NEWCLONE is not. C.