Add kqueue1(2) syscall

[kib]

Summary

It adds an ability to atomically set O_CLOEXEC on the new kqueue descriptor.
I noted that something like this is missing during read of tokio-rs/mio kqueue implementation.

The naming is chosen to follow dup3()/accept4() pattern.

[jhb]

I would maybe suggest KQ_CLOEXEC or KQUEUE_CLOEXEC as the flag name. In particular, if we ever needed kqueue2 in the future for some reason it would likely also still accept the flags argument and then the current name would be a bit odd. I think one of those names more closely matches SOCK_NONBLOCK and SOCK_CLOEXEC used with accept4.

[emaste]

agree w/ @jhb on the flag name. I've also assumed that 2 is the first "version suffix" used, that kqueue is implicitly "kqueue1" , like dup, dup2, dup3. Was there ever a dup1 that has since been removed?

Other than quibbling over naming the change looks good to me

[jhb]

In D39271#894521, @emaste wrote:

agree w/ @jhb on the flag name. I've also assumed that 2 is the first "version suffix" used, that kqueue is implicitly "kqueue1" , like dup, dup2, dup3. Was there ever a dup1 that has since been removed?

Other than quibbling over naming the change looks good to me

The number is the number of arguments, for the "new style" like dup3, pipe2, and accept4. dup2 pre-dates that scheme, but kqueue1 is consistent with the number-of-arguments suffix scheme.

[imp]

dup(2) dates to the earliest days of Unix. It's present in V6, but dup2(2) doesn't appear until V7. If there ever was a dup1, no vestige of it survived in the Unix line.

Name quibbling and way-back-machine operation aside, the code looks fine. I generally agree with john and ed on naming issues they've raised.

[emaste]

Huh, learned something new today. In that case I'd just echo John's comment on the KQ1 flag prefix.

[kib]

Rename KQ1_ to KQUEUE

[jhb]

lib/libc/sys/kqueue.2

99

Wording suggestion borrowed from pipe2(2).