On Tue, Oct 30, 2018 at 09:24:00PM -0700, Joel Fernandes wrote: > On Tue, Oct 30, 2018 at 7:56 PM, Aleksa Sarai <cyp...@cyphar.com> wrote: > > On 2018-10-31, Christian Brauner <christian.brau...@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? - Joel
