From: Christian Brauner <christian@brauner.io>
To: Daniel Colascione <dancol@google.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Joel Fernandes <joel@joelfernandes.org>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: pidfd design
Date: Wed, 20 Mar 2019 22:00:11 +0100 [thread overview]
Message-ID: <20190320210009.hhgtcu4wkvsxg4sa@brauner.io> (raw)
In-Reply-To: <CAKOZueudv0fnOUPFyXHakgrqjiNz3zF+xckN1xGk93wTY7sjuw@mail.gmail.com>
On Wed, Mar 20, 2019 at 01:50:43PM -0700, Daniel Colascione wrote:
> On Wed, Mar 20, 2019 at 1:47 PM Christian Brauner <christian@brauner.io> wrote:
> >
> > On Wed, Mar 20, 2019 at 11:39:10PM +0300, Alexey Dobriyan wrote:
> > > On Wed, Mar 20, 2019 at 01:14:01PM -0700, Daniel Colascione wrote:
> > > > On Wed, Mar 20, 2019 at 1:07 PM Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > > > > > What would be your opinion to having a
> > > > > > /proc/<pid>/handle
> > > > > > file instead of having a dirfd.
> > > > >
> > > > > This is even worse than depending on PROC_FS. Just for the dependency
> > > > > pidfd code should be backed out immediately. Forget about /proc.
> > > >
> > > > We already have pidfds, and we've had them since /proc was added ages
> > > > ago.
> > >
> > > New pidfd code (or whatever the name) should NOT depend on /proc and
> > > should not interact with VFS at all at any point (other than probably
> > > being a descriptor on a fake filesystem). The reason is that /proc is
> > > full of crap and you don't want to spill that into new and hopefully
> > > properly designed part of new code.
> >
> > Yes, I agree. That's why I was thinking that translate_pid() is a good
> > candidate to provide that decoupling.
>
> Then again: how do you propose fetching process metadata? If you adopt
> a stance that nothing can use procfs and simultaneously adopt a stance
> that we don't want to duplicate all the decades of metadata interfaces
> in /proc/pid (which are useful, not "crap"), then the overall result
> is that we just won't make any progress at all. There's nothing wrong
> with taking a dependency on procfs: procfs is how we talk about
> processes. It's completely unreasonable to say "no, you can't use the
> old thing" and also "no, we can't add a new thing that would duplicate
> the old thing".
This style or arguing won't get us any further. Please, send in the code
that you think is right and you want to get reviewed. If you can get the
Acks from the people you need, good.
next prev parent reply other threads:[~2019-03-20 21:00 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 20:07 pidfd design Alexey Dobriyan
2019-03-20 20:14 ` Daniel Colascione
2019-03-20 20:39 ` Alexey Dobriyan
2019-03-20 20:47 ` Christian Brauner
2019-03-20 20:50 ` Daniel Colascione
2019-03-20 21:00 ` Christian Brauner [this message]
2019-03-22 14:04 ` Michael Tirado
2019-03-25 17:45 ` Linus Torvalds
2019-03-25 16:14 ` Michael Tirado
2019-03-25 20:45 ` Christian Brauner
2019-03-25 18:50 ` Christian Brauner
-- strict thread matches above, loose matches on Subject: below --
2019-03-16 18:57 [RFC] simple_lmk: Introduce Simple Low Memory Killer for Android Christian Brauner
2019-03-16 19:37 ` Suren Baghdasaryan
2019-03-17 1:53 ` Joel Fernandes
2019-03-17 11:42 ` Christian Brauner
2019-03-17 15:40 ` Daniel Colascione
2019-03-18 0:29 ` Christian Brauner
2019-03-18 23:50 ` Joel Fernandes
2019-03-19 22:14 ` Christian Brauner
2019-03-19 22:48 ` Daniel Colascione
2019-03-19 23:10 ` Christian Brauner
2019-03-20 1:52 ` Joel Fernandes
2019-03-20 2:42 ` pidfd design Daniel Colascione
2019-03-20 3:59 ` Christian Brauner
2019-03-20 7:02 ` Daniel Colascione
2019-03-20 11:33 ` Joel Fernandes
2019-03-20 11:33 ` Joel Fernandes
2019-03-20 18:26 ` Christian Brauner
2019-03-20 18:38 ` Daniel Colascione
2019-03-20 18:51 ` Christian Brauner
2019-03-20 18:58 ` Andy Lutomirski
2019-03-20 19:14 ` Christian Brauner
2019-03-20 19:40 ` Daniel Colascione
2019-03-21 17:02 ` Andy Lutomirski
2019-03-25 20:13 ` Jann Horn
2019-03-25 20:13 ` Jann Horn
2019-03-25 20:23 ` Daniel Colascione
2019-03-25 20:23 ` Daniel Colascione
2019-03-25 23:42 ` Andy Lutomirski
2019-03-25 23:42 ` Andy Lutomirski
2019-03-25 23:45 ` Christian Brauner
2019-03-25 23:45 ` Christian Brauner
2019-03-26 0:00 ` Andy Lutomirski
2019-03-26 0:00 ` Andy Lutomirski
2019-03-26 0:12 ` Christian Brauner
2019-03-26 0:12 ` Christian Brauner
2019-03-26 0:24 ` Andy Lutomirski
2019-03-26 0:24 ` Andy Lutomirski
2019-03-28 9:21 ` Christian Brauner
2019-03-28 9:21 ` Christian Brauner
2019-03-20 19:19 ` Joel Fernandes
2019-03-20 19:29 ` Daniel Colascione
2019-03-24 14:44 ` Serge E. Hallyn
2019-03-24 18:48 ` Joel Fernandes
2019-03-20 19:11 ` Joel Fernandes
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=20190320210009.hhgtcu4wkvsxg4sa@brauner.io \
--to=christian@brauner.io \
--cc=adobriyan@gmail.com \
--cc=dancol@google.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.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.