On Mon, May 20, 2024 at 10:29:12AM +0200, Alejandro Colomar wrote:

On Mon, May 20, 2024 at 07:02:39AM GMT, Emanuele Torre wrote:

quoted

So probably the best solution is to just make the pidfd_open(2),
pidfd_send_signal(2), and pidfd_getfd(2) man pages tell users to include
sys/pidfd.h and call the GNU libc functions instead of including
sys/syscall.h and unistd.h and calling syscall(2) directly; now that
sys/pidfd.h exists.

Ahh, interesting.  I'm using glibc 2.38 and still don't have that one.
It seems added in 2.39.  We can directly document that in
pidfd_getfd(2).

quoted

And maybe to also add a pidfd_getpid(3) man page for the new pidfd
helper function.

No, usually we document the glibc wrapper in man2, unless there's a big
difference between the kernel syscall and the glibc wrapper.

pidfd_getpid() does not have much to do with pidfd_getfd(2), and it does
not call pidfd_* syscalls either.

As far as I understand (I have never tried to use it in a program),

  pid_t pid = pidfd_getfd(pidfd);

Is equivalent to the following command in shell:

  pid=$(grep -Pom1 '^Pid:\t\K.*' /proc/self/fdinfo/"$pidfd" || echo -1)

It reads the /proc/self/fdinfo file corresponding to the given fd and
returns the value of the "Pid" field as a pid_t, or -1.

o/
 emanuele6