> What if I want to prevent a process from forking while I want to create new > EVFILT_PROC events? Say, to accept the pid of a sibling fork from a pipe > and load it into a kqueue. Is there a reason why waitpid() isn't beholden > to this, or is there a reason that EVFILT_PROC is?
Your usage case doesn't seem like boring normal code. pledge is designed to serve two goals: (1) encourage refactoring towards safer models (2) reduce code exposure to the kernel The pledge you are talking about is called "proc" rather than "fork" for a reason -- it annotates code that attempts to reason about process-trees as much as possible. I can't specifically say what reasoning about a process means, but a reasonable edge was chosen to allow code to work. Pledge contains a few cases where further syscalls are allowed because too much existing code uses it; similarily other syscalls contain narrow checks internally as you just discovered because a feature wasn't found neccessary. waitpid was left in "stdio" because we found too much needing to be syncronously aware of sub-process termination; we also found found which used SIGCHLD and waitpid, but we found none using this non-POSIX kqueue extension in this manner. It is too complicated to explain all these details in the manual page. Also strict explanation would be a trap for program developers and kernel developers in the future. The manual page is EXPLICITLY vague as a result. Actually, I forced the removal of information that was too detailed. If you can't make pledge work in a certain way, don't use it. Or refactor your program to not rely on the narrowest extensions you find. Oh and you want a final answer? If we allow EVFILT_PROC to work in "stdio", then around 200 programs suddenly can flow through that kernel code path. See point (2) above.
