All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Christian Brauner <christian.brauner@canonical.com>
Cc: Joel Fernandes <joel@joelfernandes.org>,
	Aleksa Sarai <cyphar@cyphar.com>,
	Daniel Colascione <dancol@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Tim Murray <timmurray@google.com>,
	Suren Baghdasaryan <surenb@google.com>,
	ebiederm@xmission.com, luto@amacapital.net, serge@hallyn.com
Subject: Re: [RFC PATCH] Implement /proc/pid/kill
Date: Fri, 2 Nov 2018 14:34:17 +0000	[thread overview]
Message-ID: <20181102143417.GA19304@mail.hallyn.com> (raw)
In-Reply-To: <20181102094602.z5otkwrqtchpuhfm@gmail.com>

Quoting Christian Brauner (christian.brauner@canonical.com):
> On Thu, Nov 01, 2018 at 01:40:59PM -0700, Joel Fernandes wrote:
> > On Tue, Oct 30, 2018 at 09:24:00PM -0700, Joel Fernandes wrote:
> > > On Tue, Oct 30, 2018 at 7:56 PM, Aleksa Sarai <cyphar@cyphar.com> wrote:
> > > > On 2018-10-31, Christian Brauner <christian.brauner@canonical.com> wrote:
> > > >> > I think Aleksa's larger point is that it's useful to treat processes
> > > >> > as other file-descriptor-named, poll-able, wait-able resources.
> > > >> > Consistency is important. A process is just another system resource,
> > > >> > and like any other system resource, you should be open to hold a file
> > > >> > descriptor to it and do things to that process via that file
> > > >> > descriptor. The precise form of this process-handle FD is up for
> > > >> > debate. The existing /proc/$PID directory FD is a good candidate for a
> > > >> > process handle FD, since it does almost all of what's needed. But
> > > >> > regardless of what form a process handle FD takes, we need it. I don't
> > > >> > see a case for continuing to treat processes in a non-unixy,
> > > >> > non-file-descriptor-based manner.
> > > >>
> > > >> That's what I'm proposing in the API for which I'm gathering feedback.
> > > >> I have presented parts of this in various discussions at LSS Europe last week
> > > >> and will be at LPC.
> > > >> We don't want to rush an API like this though. It was tried before in
> > > >> other forms
> > > >> and these proposals didn't make it.
> > > >
> > > > :+1: on a well thought-out and generic proposal. As we've discussed
> > > > elsewhere, this is an issue that really would be great to (finally)
> > > > solve.
> > > 
> > > Excited to see this and please count me in for discussions around this. thanks.
> > > 
> > 
> > Just a quick question, is there a track planned at LPC for discussing this
> > new proposal or topics around/related to the proposal?
> > 
> > If not, should that be planned?
> 
> There isn't currently one planned but I'm happy to have a hallway track
> session around this.
> 
> But note, I think not all relevant people are going to be there (e.g.
> Andy). File descriptors for processes seems interesting to a lot of
> people so I'm going to send out a pitch of the idea I have and see how
> much I'm going to get yelled at latest on Tuesday. Even if it just
> triggers a design discussion.
> I have been urged by people I pitched this to to send it to lkml
> already. Sorry for the delay and the initial non-transparency. The only
> reason I didn't do it right away was to ensure that this idea is not
> completely crazy. :) (Eric probably still thinks I am though. :))
> It's just that I'm at a conference and I want to have a nicer writeup of
> this. Given the speed with which this is all coming I have given up on
> preparing a first set of patches. :)
> 
> Christian

Sounds good, thanks, looking forward to it.

  reply	other threads:[~2018-11-02 14:34 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-29 22:10 [RFC PATCH] Implement /proc/pid/kill Daniel Colascione
2018-10-30  3:21 ` Joel Fernandes
2018-10-30  8:50   ` Daniel Colascione
2018-10-30 10:39     ` Christian Brauner
2018-10-30 10:40       ` Christian Brauner
2018-10-30 10:48         ` Daniel Colascione
2018-10-30 11:04           ` Christian Brauner
2018-10-30 11:12             ` Daniel Colascione
2018-10-30 11:19               ` Christian Brauner
2018-10-31  5:00                 ` Eric W. Biederman
2018-10-30 17:01     ` Joel Fernandes
2018-10-30  5:00 ` Aleksa Sarai
2018-10-30  9:05   ` Daniel Colascione
2018-10-30 20:45     ` Aleksa Sarai
2018-10-30 21:42       ` Joel Fernandes
2018-10-30 22:23         ` Aleksa Sarai
2018-10-30 22:33           ` Joel Fernandes
2018-10-30 22:49             ` Aleksa Sarai
2018-10-31  0:42               ` Joel Fernandes
2018-10-31  1:59                 ` Daniel Colascione
2018-10-30 23:10             ` Daniel Colascione
2018-10-30 23:23               ` Christian Brauner
2018-10-30 23:55                 ` Daniel Colascione
2018-10-31  2:56                 ` Aleksa Sarai
2018-10-31  4:24                   ` Joel Fernandes
2018-11-01 20:40                     ` Joel Fernandes
2018-11-02  9:46                       ` Christian Brauner
2018-11-02 14:34                         ` Serge E. Hallyn [this message]
2018-10-31  0:57               ` Joel Fernandes
2018-10-31  1:56                 ` Daniel Colascione
2018-10-31  4:47   ` Eric W. Biederman
2018-10-31  4:44 ` Eric W. Biederman
2018-10-31 12:44   ` Oleg Nesterov
2018-10-31 13:27     ` Daniel Colascione
2018-10-31 15:10       ` Oleg Nesterov
2018-10-31 15:16         ` Daniel Colascione
2018-10-31 15:49           ` Oleg Nesterov
2018-11-01 11:53       ` David Laight
2018-11-01 15:50         ` Daniel Colascione
2018-10-31 14:37 ` [PATCH v2] " Daniel Colascione
2018-10-31 15:05   ` Joel Fernandes
2018-10-31 17:33     ` Aleksa Sarai
2018-10-31 21:47       ` Joel Fernandes
2018-10-31 15:59 ` [PATCH v3] " Daniel Colascione
2018-10-31 17:54   ` Tycho Andersen
2018-10-31 18:00     ` Daniel Colascione
2018-10-31 18:17       ` Tycho Andersen
2018-10-31 19:33         ` Daniel Colascione
2018-10-31 20:06           ` Tycho Andersen
2018-11-01 11:33           ` David Laight
2018-11-12  1:19             ` Eric W. Biederman
2018-10-31 16:22 ` [RFC PATCH] " Jann Horn
2018-11-01  4:53   ` Andy Lutomirski
2018-11-12 23:13 ` Pavel Machek

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=20181102143417.GA19304@mail.hallyn.com \
    --to=serge@hallyn.com \
    --cc=christian.brauner@canonical.com \
    --cc=cyphar@cyphar.com \
    --cc=dancol@google.com \
    --cc=ebiederm@xmission.com \
    --cc=joel@joelfernandes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=surenb@google.com \
    --cc=timmurray@google.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 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.