From: Daniel Colascione <dancol@google.com>
To: Jonathan Kowalski <bl0pbl33p@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
Christian Brauner <christian@brauner.io>,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>, Jann Horn <jannh@google.com>,
David Howells <dhowells@redhat.com>,
Linux API <linux-api@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
Thomas Gleixner <tglx@linutronix.de>,
Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Aleksa Sarai <cyphar@cyphar.com>,
Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH 2/4] clone: add CLONE_PIDFD
Date: Mon, 15 Apr 2019 12:39:01 -0700 [thread overview]
Message-ID: <CAKOZuetPpE6-HrV0uV=fWosOnQkaq5eSQHyiARS6LUensuWBbg@mail.gmail.com> (raw)
In-Reply-To: <CAGLj2rHpZ92txk2=yf7dtHFcic2H0bGB0=FzEo7w2rNpC2zxDA@mail.gmail.com>
On Mon, Apr 15, 2019 at 10:15 AM Jonathan Kowalski <bl0pbl33p@gmail.com> wrote:
> > Why else do we want pidfd?
>
> Apart from what others have already pointed out, there are two other
> things I am looking forward to:
Everything that Christian, Joel, and Jonathan have said is right.
If I can wax philosophical for a bit (as I've been accused to doing
:-)), there's a lot of value in consistency itself, a "more than the
sum of its parts" effect that arises from modeling all kernel-resource
handles as file descriptors. You get lifecycle consistency, API
consistency (e.g., dup, close), introspection consistency (via
/proc/pid/fd and friends), wait consistency, IPC consistency, and tons
of other benefits from using a file descriptor. The alternatives tend
to be very ugly: one of SysV IPC's* biggest mistakes, for example, was
having users manage its resources via non-file-descriptor kernel
handles. The process is, I think, the last major class of kernel
resource that users can't manipulate via file descriptor. Even if
using pidfds didn't provide strong immediate and direct benefits, it'd
*still* be worth moving to a file descriptor resource handle model for
the sake of making the system interface regular and uniform.
* Does anyone know *why* the SysV people didn't use FDs? The
consistency argument I'm making was just as relevant then as it is
now.
next prev parent reply other threads:[~2019-04-15 19:39 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-14 20:14 [PATCH 0/4] clone: add CLONE_PIDFD Christian Brauner
2019-04-14 20:14 ` [PATCH 1/4] Make anon_inodes unconditional Christian Brauner
2019-04-14 20:14 ` [PATCH 2/4] clone: add CLONE_PIDFD Christian Brauner
2019-04-15 10:52 ` Oleg Nesterov
2019-04-15 11:42 ` Christian Brauner
2019-04-15 13:24 ` Oleg Nesterov
2019-04-15 13:52 ` Christian Brauner
2019-04-15 16:25 ` Joel Fernandes
2019-04-15 17:15 ` Jonathan Kowalski
2019-04-15 19:39 ` Daniel Colascione [this message]
2019-04-14 20:14 ` [PATCH 3/4] signal: support CLONE_PIDFD with pidfd_send_signal Christian Brauner
2019-04-14 20:14 ` [PATCH 4/4] samples: show race-free pidfd metadata access Christian Brauner
2019-04-15 10:08 ` RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD] Enrico Weigelt, metux IT consult
2019-04-15 15:50 ` Serge E. Hallyn
2019-04-16 18:32 ` Enrico Weigelt, metux IT consult
2019-04-29 15:49 ` Serge E. Hallyn
2019-04-29 17:31 ` Enrico Weigelt, metux IT consult
2019-05-05 2:32 ` Serge E. Hallyn
2019-04-15 19:59 ` Aleksa Sarai
2019-04-15 20:29 ` Andy Lutomirski
2019-04-15 21:27 ` Jonathan Kowalski
2019-04-15 23:58 ` Andy Lutomirski
2019-04-15 23:58 ` Andy Lutomirski
2019-04-16 18:45 ` Enrico Weigelt, metux IT consult
2019-04-16 21:31 ` Andy Lutomirski
2019-04-17 12:03 ` Enrico Weigelt, metux IT consult
2019-04-17 12:54 ` Christian Brauner
2019-04-18 15:46 ` Enrico Weigelt, metux IT consult
2019-04-17 12:19 ` Florian Weimer
2019-04-17 12:19 ` Florian Weimer
2019-04-17 16:46 ` Andy Lutomirski
2019-04-17 16:46 ` Andy Lutomirski
2019-04-20 7:14 ` Kevin Easton
2019-04-20 11:15 ` Christian Brauner
2019-04-20 15:06 ` Daniel Colascione
2019-04-29 19:30 ` Jann Horn
2019-04-29 19:55 ` Jann Horn
2019-04-29 20:21 ` Linus Torvalds
2019-04-29 20:38 ` Florian Weimer
2019-04-29 20:38 ` Florian Weimer
2019-04-29 20:51 ` Christian Brauner
2019-04-29 20:51 ` Christian Brauner
2019-04-29 21:31 ` Linus Torvalds
2019-04-29 21:31 ` Linus Torvalds
2019-04-30 7:01 ` Florian Weimer
2019-04-30 7:01 ` Florian Weimer
2019-04-30 0:38 ` Jann Horn
2019-04-30 2:16 ` Linus Torvalds
2019-04-30 8:21 ` Florian Weimer
2019-04-30 8:21 ` Florian Weimer
2019-04-30 16:19 ` Linus Torvalds
2019-04-30 16:19 ` Linus Torvalds
2019-04-30 16:26 ` Linus Torvalds
2019-04-30 16:26 ` Linus Torvalds
2019-04-30 17:07 ` Florian Weimer
2019-04-30 17:07 ` Florian Weimer
2019-04-30 12:39 ` Oleg Nesterov
2019-04-30 16:24 ` Linus Torvalds
2019-04-29 20:49 ` Florian Weimer
2019-04-29 20:49 ` Florian Weimer
2019-04-29 20:52 ` Christian Brauner
2019-04-29 20:52 ` Christian Brauner
2019-04-20 15:28 ` Al Viro
2019-04-16 18:37 ` Enrico Weigelt, metux IT consult
2019-04-15 10:16 ` [PATCH 0/4] clone: add CLONE_PIDFD Enrico Weigelt, metux IT consult
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='CAKOZuetPpE6-HrV0uV=fWosOnQkaq5eSQHyiARS6LUensuWBbg@mail.gmail.com' \
--to=dancol@google.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bl0pbl33p@gmail.com \
--cc=christian@brauner.io \
--cc=cyphar@cyphar.com \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=jannh@google.com \
--cc=joel@joelfernandes.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=oleg@redhat.com \
--cc=serge@hallyn.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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.