public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Roland McGrath <roland@redhat.com>,
	linux-kernel@vger.kernel.org, Oren Laadan <orenl@cs.columbia.edu>,
	serue@us.ibm.com, "Eric W. Biederman" <ebiederm@xmission.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Pavel Emelyanov <xemul@openvz.org>, Andrew Morton <akpm@osdl.org>,
	torvalds@linux-foundation.org, mikew@google.com, mingo@elte.hu,
	Nathan Lynch <nathanl@austin.ibm.com>,
	arnd@arndb.de, peterz@infradead.org, Louis.Rilling@kerlabs.com,
	kosaki.motohiro@jp.fujitsu.com, randy.dunlap@oracle.com,
	linux-api@vger.kernel.org,
	Containers <containers@lists.linux-foundation.org>,
	sukadev@us.ibm.com
Subject: Re: [RFC][v8][PATCH 0/10] Implement clone3() system call
Date: Wed, 14 Oct 2009 17:17:39 -0700	[thread overview]
Message-ID: <20091015001739.GC3515@us.ibm.com> (raw)
In-Reply-To: <4AD6557D.3090501@zytor.com>

H. Peter Anvin [hpa@zytor.com] wrote:
| On 10/14/2009 03:36 PM, Sukadev Bhattiprolu wrote:
| > H. Peter Anvin [hpa@zytor.com] wrote:
| > | 
| > | Overall it seems sane to:
| > | 
| > | a) make it an actual 3-argument call;
| > | b) make the existing flags a u32 forever, and make it a separate
| > |    argument;
| > | c) any new expansion can be via the struct, which may want to have
| > |    an "c3_flags" field first in the structure.
| > 
| > Ok, So will this work ?
| > 
| > 	struct clone_args {
| > 		u32 flags_high;		/* new clone flags (higher bits) */ 
| > 		u32 reserved1;
| > 		u32 nr_pids;
| > 		u32 reserved2;
| > 		u64 child_stack_base;
| > 		u64 child_stack_size;
| > 		u64 parent_tid_ptr;
| > 		u64 child_tid_ptr;
| > 		u64 reserved3;
| > 	};
| > 
| > 	sys_clone3(u32 flags_low, struct clone_args *args, pid_t *pid_list)
| > 
| > Even on 64bit architectures the applications have to use sys_clone3() for
| > the extended features.
| 
| Yes, although I'd just make flags_high a u64.

so we allow 96 bits for flags ?

| The other thing that might be worthwhile is to have a length field on
| the structure; that way we could add new fields at the end if ever
| necessary in the future.

So:
	struct clone_args {
		u64 flags_high;		/* new clone flags (higher bits) */ 
		u64 reserved1;

		u32 nr_pids;
		u32 clone_args_size;

		u64 child_stack_base;
		u64 child_stack_size;

		u64 parent_tid_ptr;
		u64 child_tid_ptr;
	};

	sys_clone3(u32 flags_low, struct clone_args *args, pid_t *pid_list)

BTW, on 64-bit architectures, the flags_low would be 64-bits, but the high-
bits there would be ignored right ?

Not sure if we need a second reserved field now that we add ->clone_args_size.

Thanks,

Sukadev

  reply	other threads:[~2009-10-15  0:16 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-13  4:49 [RFC][v8][PATCH 0/10] Implement clone3() system call Sukadev Bhattiprolu
2009-10-13  4:49 ` [RFC][v8][PATCH 1/10]: Factor out code to allocate pidmap page Sukadev Bhattiprolu
2009-10-13  4:50 ` [RFC][v8][PATCH 2/10]: Have alloc_pidmap() return actual error code Sukadev Bhattiprolu
2009-10-13  4:50 ` [RFC][v8][PATCH 3/10]: Make pid_max a pid_ns property Sukadev Bhattiprolu
2009-10-13  5:19   ` Alexey Dobriyan
2009-10-13 13:09   ` Pavel Emelyanov
2009-10-13 15:24     ` Serge E. Hallyn
2009-10-13 16:10       ` Pavel Emelyanov
2009-10-13 16:28         ` Serge E. Hallyn
2009-10-13  4:51 ` [RFC][v8][PATCH 4/10]: Add target_pid parameter to alloc_pidmap() Sukadev Bhattiprolu
2009-10-13 11:50   ` Pavel Emelyanov
2009-10-15  0:24     ` Sukadev Bhattiprolu
2009-10-13  4:51 ` [RFC][v8][PATCH 5/10]: Add target_pids parameter to alloc_pid() Sukadev Bhattiprolu
2009-10-13  4:52 ` [RFC][v8][PATCH 6/10]: Add target_pids parameter to copy_process() Sukadev Bhattiprolu
2009-10-13  4:52 ` [RFC][v8][PATCH 7/10]: Check invalid clone flags Sukadev Bhattiprolu
2009-10-13 18:35   ` Oren Laadan
2009-10-13 23:38     ` Sukadev Bhattiprolu
2009-10-13  4:52 ` [RFC][v8][PATCH 8/10]: Define do_fork_with_pids() Sukadev Bhattiprolu
2009-10-13  4:54 ` [RFC][v8][PATCH 9/10]: Define clone3() syscall Sukadev Bhattiprolu
2009-10-13 18:46   ` Oren Laadan
2009-10-16  4:20   ` Sukadev Bhattiprolu
2009-10-16  6:25     ` Michael Kerrisk
2009-10-16 18:06       ` Sukadev Bhattiprolu
2009-10-19 17:44         ` Matt Helsley
2009-10-19 21:31           ` H. Peter Anvin
2009-10-19 23:50             ` Matt Helsley
2009-10-21  4:26               ` Michael Kerrisk
2009-10-21 13:03                 ` H. Peter Anvin
2009-10-21 19:44                   ` Sukadev Bhattiprolu
2009-10-21 22:03                     ` H. Peter Anvin
2009-10-22 10:40                     ` Michael Kerrisk
2009-10-22 18:10                       ` Sukadev Bhattiprolu
2009-10-22 10:26                   ` Michael Kerrisk
2009-10-22 11:38                     ` H. Peter Anvin
2009-10-22 12:14                       ` Michael Kerrisk
2009-10-22 12:19                         ` H. Peter Anvin
2009-10-22 13:57                         ` Matt Helsley
2009-10-13  4:55 ` [RFC][v8][PATCH 10/10]: Document " Sukadev Bhattiprolu
2009-10-14 12:26   ` Arnd Bergmann
2009-10-14 18:39     ` Sukadev Bhattiprolu
2009-10-19 21:36   ` Pavel Machek
2009-10-21  8:37     ` Arnd Bergmann
2009-10-21  9:33       ` Pavel Machek
2009-10-21 13:26         ` Arnd Bergmann
2009-10-21 18:27     ` Sukadev Bhattiprolu
2009-10-13 20:50 ` [RFC][v8][PATCH 0/10] Implement clone3() system call Roland McGrath
2009-10-13 23:27   ` Sukadev Bhattiprolu
2009-10-13 23:53     ` Roland McGrath
2009-10-14  1:13       ` H. Peter Anvin
2009-10-14  4:36         ` Sukadev Bhattiprolu
2009-10-14  4:38           ` H. Peter Anvin
2009-10-14 22:36         ` Sukadev Bhattiprolu
2009-10-14 22:49           ` H. Peter Anvin
2009-10-15  0:17             ` Sukadev Bhattiprolu [this message]
2009-10-13 23:49 ` H. Peter Anvin
2009-10-14  1:39   ` Matt Helsley
2009-10-14  2:24     ` H. Peter Anvin
2009-10-14  4:40       ` Sukadev Bhattiprolu
2009-10-14  4:50         ` H. Peter Anvin
2009-10-14 16:07         ` Serge E. Hallyn
2009-10-16 19:22 ` Daniel Lezcano
2009-10-16 19:44   ` Sukadev Bhattiprolu
2009-10-19 20:34     ` Daniel Lezcano
2009-10-19 21:47       ` Oren Laadan
2009-10-20  0:51         ` Matt Helsley
2009-10-20  3:33           ` Eric W. Biederman
2009-10-20  4:03             ` Sukadev Bhattiprolu
2009-10-20 10:46               ` Eric W. Biederman
2009-10-20 14:16                 ` Serge E. Hallyn
2009-10-20 18:33                 ` Sukadev Bhattiprolu
2009-10-20 19:26                   ` Eric W. Biederman
2009-10-20 20:13                     ` Oren Laadan
2009-10-21  6:20                     ` Sukadev Bhattiprolu
2009-10-21  9:16                       ` Eric W. Biederman
2009-10-21 18:52                         ` Sukadev Bhattiprolu
2009-10-21 21:11                           ` Eric W. Biederman
2009-10-23  0:42                         ` Sukadev Bhattiprolu
2009-10-23  1:03                           ` Eric W. Biederman
2009-10-23  5:30                             ` Sukadev Bhattiprolu
2009-10-23  5:44                               ` Eric W. Biederman
2009-10-23 19:21                                 ` Sukadev Bhattiprolu
2009-10-23 20:48                                   ` Sukadev Bhattiprolu
2009-10-23 23:26                                     ` Eric W. Biederman
2009-10-24  3:38                                       ` Sukadev Bhattiprolu
2009-10-23 19:16                               ` Oren Laadan
2009-10-23 19:34                                 ` Oren Laadan
2009-10-23 23:12                                   ` Eric W. Biederman
2009-10-20 14:09             ` Serge E. Hallyn
2009-10-21 15:53         ` Daniel Lezcano
2009-10-21 18:45           ` Oren Laadan
2009-10-22 11:22             ` Daniel Lezcano
  -- strict thread matches above, loose matches on Subject: below --
2009-10-26  9:38 Albert Cahalan

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=20091015001739.GC3515@us.ibm.com \
    --to=sukadev@linux.vnet.ibm.com \
    --cc=Louis.Rilling@kerlabs.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@osdl.org \
    --cc=arnd@arndb.de \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikew@google.com \
    --cc=mingo@elte.hu \
    --cc=nathanl@austin.ibm.com \
    --cc=orenl@cs.columbia.edu \
    --cc=peterz@infradead.org \
    --cc=randy.dunlap@oracle.com \
    --cc=roland@redhat.com \
    --cc=serue@us.ibm.com \
    --cc=sukadev@us.ibm.com \
    --cc=torvalds@linux-foundation.org \
    --cc=xemul@openvz.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