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
next prev 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.