Re: Would we want pidfd_open(2) & SO_PEERPIDFD?
- In reply to: Gleb Popov : "Re: Would we want pidfd_open(2) & SO_PEERPIDFD?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.