From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christian Brauner <christian@brauner.io>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Jann Horn <jannh@google.com>, Florian Weimer <fweimer@redhat.com>,
Oleg Nesterov <oleg@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
David Howells <dhowells@redhat.com>,
Pavel Emelyanov <xemul@virtuozzo.com>,
Andrew Morton <akpm@linux-foundation.org>,
Adrian Reber <adrian@lisas.de>, Andrei Vagin <avagin@gmail.com>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH 1/2] fork: add clone6
Date: Mon, 27 May 2019 12:27:08 -0700 [thread overview]
Message-ID: <CAHk-=wjnbK5ob9JE0H1Ge_R4BL6D0ztsAvrM6DN+S+zyDWE=7A@mail.gmail.com> (raw)
In-Reply-To: <20190527104239.fbnjzfyxa4y4acpf@brauner.io>
On Mon, May 27, 2019 at 3:42 AM Christian Brauner <christian@brauner.io> wrote:
>
> Hm, still pondering whether having one unsigned int argument passed
> through registers that captures all the flags from the old clone() would
> be a good idea.
That sounds like a reasonable thing to do.
Maybe we could continue to call the old flags CLONE_XYZ and continue
to pass them in as "flags" argument, and then we have CLONE_EXT_XYZ
flags for a new 64-bit flag field that comes in through memory in the
new clone_args thing?
That would make the flag arguments less "unified", but might make for
a simpler patch, and might make it easier for the old interfaces to
just pass in the clone flags they already have in registers instead of
setting them up in the clone_args structure.
I don't think it's necessarily wrong for the interface to show some
effects of legacy models, as long as we don't have those kinds of "if
(is_clone6)" nasties.
Linus
next prev parent reply other threads:[~2019-05-27 19:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-26 10:26 [PATCH 1/2] fork: add clone6 Christian Brauner
2019-05-26 10:26 ` [PATCH 2/2] arch: wire-up clone6() syscall on x86 Christian Brauner
2019-05-27 10:02 ` Arnd Bergmann
2019-05-27 10:45 ` Christian Brauner
2019-05-27 12:28 ` Arnd Bergmann
2019-05-27 12:34 ` Christian Brauner
2019-05-27 18:48 ` Linus Torvalds
2019-05-26 16:50 ` [PATCH 1/2] fork: add clone6 Linus Torvalds
2019-05-27 10:42 ` Christian Brauner
2019-05-27 19:27 ` Linus Torvalds [this message]
2019-05-27 19:36 ` Jann Horn
2019-05-30 18:26 ` Kees Cook
2019-05-28 10:08 ` Christian Brauner
2019-05-28 14:15 ` Andy Lutomirski
2019-05-28 15:23 ` Eric W. Biederman
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='CAHk-=wjnbK5ob9JE0H1Ge_R4BL6D0ztsAvrM6DN+S+zyDWE=7A@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=adrian@lisas.de \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=avagin@gmail.com \
--cc=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=fweimer@redhat.com \
--cc=jannh@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xemul@virtuozzo.com \
/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;
as well as URLs for NNTP newsgroup(s).