[Devel] Re: [RFC][v4][PATCH 7/7]: Define clone_extended() syscall

Serge E. Hallyn serue at us.ibm.com
Thu Aug 6 09:16:17 PDT 2009


Quoting Oren Laadan (orenl at librato.com):
> >>>> The proposed interface for clone_extended() is:
> >>>>
> >>>> 	struct clone_tid_info {
> >>>> 		void *parent_tid; 	/* parent_tid_ptr parameter */
> >>>> 		void *child_tid; 	/* child_tid_ptr parameter */
> >>>> 	};
> >>>>
> >>>> 	struct pid_set {
> >>>> 		int num_pids;
> >>>> 		pid_t *pids;
> >>>> 	};
> >>>>
> >>>> 	int clone_extended(int flags_low, int flags_high, void *child_stack,
> >>>> 			void *unused, struct clone_tid_info *tid_ptrs,
> >>>> 			struct pid_set *pid_setp);
> >>> I was thinking additional flags would be passed in the (renamed)
> >>> struct pid_set.
> >> Yes.
> >>
> >> But maybe in (renamed) 'struct clone_info' instead of 'struct pid_set' ?
> >>
> >> I vaguely recall a strong preference to not require copy-from-user
> >> during a fast-path clone, because it may hurt performance.
> >>
> >> *If* this is the case, then maybe place extra flags among the
> >> "base" args, or at least a CLONE_EXTRA would indicate that more
> >> arguments need to be pulled from user-space ?
> > 
> > Wouldn't passing NULL for struct clone_info suffice?
> 
> :o
> 
> Actually, I misread the original prototype, and I prefer Suka's
> current suggestion.

I think Suka's suggestion is again inherently limited (in # of
clone flags) and will force even uglier syscalls for each arch than the
previous one already does.

-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