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: > > 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). > > > 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
