Linux Container Development
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Sukadev Bhattiprolu
	<sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Containers
	<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Alexey Dobriyan
	<adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [RFC][v4][PATCH 7/7]: Define clone_extended() syscall
Date: Thu, 6 Aug 2009 13:35:15 -0500	[thread overview]
Message-ID: <20090806183515.GA4280@us.ibm.com> (raw)
In-Reply-To: <20090806182340.GA2579-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

Quoting Sukadev Bhattiprolu (sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> | 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.
> | 
> 
> Yes other architectures are forced to ignore the flags_high and copy-in the
> tid pointers.
> 
> But if we want more than 64 bit flags, we may need follow the sigset_t 
> model ?
> 
> Also, I am listing three approaches below. Do you prefer #2 below ?

I prefer #2 with 'struct pid_set' renamed to clone_ext_data or something,
and either a version # or int num_clone_words so we can add clone flags
later.  I know, adding more then 32 more clone flags seems unlikely, but...

> 1. =====
> 
>         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);
> 
> 2. ======
> 
> 	struct clone_info {
> 		int flags_high;
> 		struct pid_set pid_set;
> 	}
> 
>         int clone_extended(int flags_low, void *child_stack, void *unused,
> 		int *parent_tid, int *child_tid, struct clone_info *clone_info);
> 
> 
> 	Pros:
> 		- copy_from_user() needed only for new flags and pid_set
> 
> 	Cons:
> 		- splitting the high and low clone-flags is awkward ?
> 
> 3. =====
> 
> 	typedef struct {
> 		unsigned long flags[N_CLONE_FLAGS];
> 	} clone_flags_t;
> 
> 	int clone_extended(clone_flags_t *flags, void *child_stack, int *unused,
> 		int *parent_tid, int *child_tid, struct pid_set *pid_set);
> 
> 
> 	Pros:
> 		- extendible clone_flags (like sigset_t)
> 		- no copy_from_user() when we have 32 clone-flags
> 		- no copy_from_user for tids
> 
> 	Cons:
> 		- copy_from_user() needed on 32-bit architectures for all flags
> 		  when they exceed 32.
> 
> 
> Sukadev

  parent reply	other threads:[~2009-08-06 18:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06  6:10 [RFC][v4][PATCH 0/7] clone_extended() syscall Sukadev Bhattiprolu
     [not found] ` <20090806061056.GA1044-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-06  6:22   ` [RFC][v4][PATCH 1/7] Factor out code to allocate pidmap page Sukadev Bhattiprolu
2009-08-06  6:23   ` [RFC][v4][PATCH 2/7]: Have alloc_pidmap() return actual error code Sukadev Bhattiprolu
2009-08-06  6:23   ` [RFC][v4][PATCH 3/7]: Add target_pid parameter to alloc_pidmap() Sukadev Bhattiprolu
2009-08-06  6:24   ` [RFC][v4][PATCH 4/7]: Add target_pids parameter to alloc_pid() Sukadev Bhattiprolu
2009-08-06  6:24   ` [RFC][v4][PATCH 5/7]: Add target_pids parameter to copy_process() Sukadev Bhattiprolu
2009-08-06  6:24   ` [RFC][v4][PATCH 6/7]: Define do_fork_with_pids() Sukadev Bhattiprolu
2009-08-06  6:25   ` [RFC][v4][PATCH 7/7]: Define clone_extended() syscall Sukadev Bhattiprolu
     [not found]     ` <20090806062505.GG5619-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-06 13:38       ` Serge E. Hallyn
     [not found]         ` <20090806133847.GA28392-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-06 15:37           ` Oren Laadan
     [not found]             ` <4A7AF8AD.4070805-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
2009-08-06 15:55               ` Serge E. Hallyn
     [not found]                 ` <20090806155520.GA904-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-06 16:05                   ` Oren Laadan
     [not found]                     ` <4A7AFF61.8050802-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
2009-08-06 16:16                       ` Serge E. Hallyn
     [not found]                         ` <20090806161616.GA1472-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-06 18:23                           ` Sukadev Bhattiprolu
     [not found]                             ` <20090806182340.GA2579-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-06 18:35                               ` Serge E. Hallyn [this message]
2009-08-06 20:38       ` Matt Helsley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090806183515.GA4280@us.ibm.com \
    --to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=sukadev-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox