Date: Wed, 12 Feb 2025 07:16:57 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Gleb Popov <arrowd@freebsd.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Would we want pidfd_open(2) & SO_PEERPIDFD? Message-ID: <Z6wuyS4uBQJbCG-c@kib.kiev.ua> In-Reply-To: <CALH631=7MnCAe67yPqG%2BAJfy_CPxf3HUxsfeVvgmiTEXEy27Bg@mail.gmail.com> References: <CALH631mgztNmngL1Hffbbcf0n-kLZP-2YmsMLJ8Xi33HV8uuvw@mail.gmail.com> <Z6udhDuj4uBjNUsM@kib.kiev.ua> <CALH631=7MnCAe67yPqG%2BAJfy_CPxf3HUxsfeVvgmiTEXEy27Bg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Starting with the termination behavior and the availability of the wait(2) family of syscalls both on original pid and pidfd (that does not work after converting child pid to pidfd), to sending signals, and detail of the poll(2) events definitions etc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z6wuyS4uBQJbCG-c>