On Mon, May 20, 2024 at 11:12:45AM GMT, Emanuele Torre wrote: > 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. Ahh, sorry, I got confused with so many similarly called functions. Anyway, we need to document that glibc added wrappers for them. > > 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 -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
