Re: Would we want pidfd_open(2) & SO_PEERPIDFD?

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Wed, 12 Feb 2025 06:44:16 UTC
On Wed, Feb 12, 2025 at 08:24:36AM +0300, Gleb Popov wrote:
> On Wed, Feb 12, 2025 at 8:17 AM Konstantin Belousov <kostikbel@gmail.com> wrote:
> >
> > On Wed, Feb 12, 2025 at 07:10:25AM +0300, Gleb Popov wrote:
> > > On Tue, Feb 11, 2025 at 9:57 PM Konstantin Belousov <kostikbel@gmail.com> wrote:
> > > >
> > > >
> > > > The semantic of the Linux' fd returned by pidfd_open() is not compatible
> > > > with our pidfd.
> > >
> > > What's the difference, exactly?
> > > I mean, it is still a descriptor and the only thing I need to do with
> > > it is check if it is still open. We even have pdgetpid() to go from
> > > the fd to a PID. This all looks like a perfect match to me.
> >
> > Read the man page for Linux pidfd_open(), and compare with our procdesc(4).
> > The one feature _you plan to use_ might be almost identical, but everything
> > else is different.
> 
> So, that's a "no" to my original question and my way forward is
> patching D-Bus itself?
This most likely provides the no answer to your first question.
For the second one, you probably need to explain more what do you try
to achieve.