public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Emanuele Torre <torreemanuele6@gmail.com>
To: alx@kernel.org
Cc: linux-man@vger.kernel.org
Subject: pidfd_open.2: PIDFD_NONBLOCK is not defined by the listed headers
Date: Mon, 20 May 2024 07:02:39 +0200	[thread overview]
Message-ID: <ZkrZb91EgZoaOybZ@t420> (raw)

Hello.


pidfd_open(2) only lists sys/syscall.h and unistd.h in its SYNOPSYS:

  SYNOPSIS
         #include <sys/syscall.h>      /* Definition of SYS_* constants */
         #include <unistd.h>

         int syscall(SYS_pidfd_open, pid_t pid, unsigned int flags);

         Note:  glibc provides no wrapper for pidfd_open(), necessitating
         the use of syscall(2).

Then it mentions PIDFD_NONBLOCK as one of its flags:

  PIDFD_NONBLOCK (since Linux 5.10)
         Return  a nonblocking file descriptor.  If the process referred
         to by the file descriptor has not yet terminated, then  an  at‐
         tempt to wait on the file descriptor using waitid(2) will imme‐
         diately return the error EAGAIN rather than blocking.

But PIDFD_NONBLOCK is not defined in any of the listed headers.


I have noticed that PIDFD_NONBLOCK is the same value as O_NONBLOCK,
so perhaps this flag could be listed as

  O_NONBLOCK or PIDFD_NONBLOCK (since Linux 5.10)

like O_NDELAY and O_NONBLOCK in open.2.

This way the user would know that O_NONBLOCK may be used instead of
PIDFD_NONBLOCK if PIDFD_NONBLOCK is not available.


I have also noticed that GNU libc (in its linux-api-headers submodule)
provides a linux/pidfd.h header that just defines PIDFD_NONBLOCK as
O_NONBLOCK, perhaps another solution would be to list in linux/pidfd.h
in the synopsis and say it is required to use PIDFD_NONBLOCK.


Then, I also noticed that GNU libc now also provides the sys/pidfd.h
header with the definition of PIDFD_NONBLOCK, and prototypes for
pidfd_open, pidfd_send_signal, pidfd_getfd, and also a prototype for
pidfd_getpid that is an helper function that parses the "Pid:" field
from /proc/self/fdinfo/FD and currently does not have a man page.

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.

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


o/
 emanuele6

             reply	other threads:[~2024-05-20  5:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-20  5:02 Emanuele Torre [this message]
2024-05-20  8:29 ` pidfd_open.2: PIDFD_NONBLOCK is not defined by the listed headers Alejandro Colomar
2024-05-20  8:53   ` Alejandro Colomar
2024-05-20 11:35     ` Adhemerval Zanella Netto
2024-11-01 13:27       ` Alejandro Colomar
2024-05-20  9:12   ` Emanuele Torre
2024-05-20  9:42     ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZkrZb91EgZoaOybZ@t420 \
    --to=torreemanuele6@gmail.com \
    --cc=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox