On Wed, Mar 20, 2019 at 1:47 PM Christian Brauner <christ...@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 <adobri...@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".
