Date: Sat, 18 Sep 2021 10:26:29 -0700
From: Jason Thorpe <thor...@me.com>
Message-ID: <986563ad-88c2-41b9-bf69-51b26240b...@me.com>
| https://www.netbsd.org/~thorpej/timerfd.2
This one contains duplicated text...
Because they are associated with a file descriptor, they may be passed
to other processes, inherited across a fork, and multiplexed using
.Xr kevent ,
.Xr poll ,
or
.Xr select they are associated with a file descriptor, they may be passed
to other processes, inherited across a fork, and multiplexed using
.Xr kevent 2 ,
.Xr poll 2 ,
or
.Xr select 2 .
That should be fixed before anything is committed.
Apart from that both man pages contain text like
unless the
.Nm
object was created with
.Dv TFD_NONBLOCK .
Since these things are working with file descriptors, I assume that
fcntl(2) can be used to manipulate flags like O_NONBLOCK and O_CLOEXEC
in which case I would guess (and hope) that the state of those flags when the
object was created isn't what is releant, but the state of the flags at
the time of the operation concerned.
The man pages should probably be reworded with that in mind.
The exact relationships of the {event,timer}fd_*() functions
and read()/write() is also not clear to me - are those just wrappers
around read/write or are they distinct sys calls of their own?
I initially assumed the former, but then I see that timerfd_settimer()
has an extra flags arg, which write() (I presume) has no easy way to
pass in, so now I am not sure.
If these are distinct operations how to actual read()/write() interact?
What would the flags be on a write()?
Finally, what does fstat() return about these fds? What is the dev_t ?
What is the inode number, is the link count meaningfil, how about the
uid and permissions? And what affects the time fields?
I suspect that regardless of the merits of the interfaces, the specs
need some improvement.
kre
