[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjnbK5ob9JE0H1Ge_R4BL6D0ztsAvrM6DN+S+zyDWE=7A@mail.gmail.com>
Date: Mon, 27 May 2019 12:27:08 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian Brauner <christian@...uner.io>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Jann Horn <jannh@...gle.com>,
Florian Weimer <fweimer@...hat.com>,
Oleg Nesterov <oleg@...hat.com>, Arnd Bergmann <arnd@...db.de>,
David Howells <dhowells@...hat.com>,
Pavel Emelyanov <xemul@...tuozzo.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Adrian Reber <adrian@...as.de>,
Andrei Vagin <avagin@...il.com>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH 1/2] fork: add clone6
On Mon, May 27, 2019 at 3:42 AM Christian Brauner <christian@...uner.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
Powered by blists - more mailing lists