在 ioctl 中打开的不良副作用是什么？
What are the unwanted side effects of open in ioctl?
根据 man ioctl，使用 open 打开文件描述符可能会导致不需要的副作用。该手册还指出，以 O_NONBLOCK 开头可以解决那些不需要的问题，但我似乎无法找到原因是什么，也不知道实际的副作用是什么。有人可以阐明这一点吗？使用 ioctl 是否总是可以并等同于使用 O_NONBLOCK 打开文件描述符？
NOTES (from man ioctl)
In order to use this call, one needs an open file descriptor. Often the open(2) call has unwanted side effects, that can be avoided
under Linux by giving it the O_NONBLOCK flag.
(* 我知道 O_NONBLOCK 意味着什么，但我不知道这是否会影响 ioctl 调用，就像影响其他系统调用一样。我的程序使用 ioctl 写入和读取 SPI 总线，在启用该标志的情况下完美工作。）
寻找答案的明显位置是 open(2) 手册页，在 O_NONBLOCK 的标题下，它说：
When possible, the file is opened in nonblocking mode.
Neither the open() nor any subsequent operations on the file
descriptor which is returned will cause the calling process to
wait.
[...]
For the handling of FIFOs (named pipes), see also fifo(7).
For a discussion of the effect of O_NONBLOCK in conjunction
with mandatory file locks and with file leases, see fcntl(2).
好的，这不是很有用，但让我们点击链接，看看 fifo(7) 和 fcntl(2) 的手册页是怎么说的：
Normally, opening the FIFO blocks until the other end is opened also.
A process can open a FIFO in nonblocking mode. In this case, opening
for read-only will succeed even if no-one has opened on the write
side yet and opening for write-only will fail with ENXIO (no such
device or address) unless the other end has already been opened.
Under Linux, opening a FIFO for read and write will succeed both in
blocking and nonblocking mode. POSIX leaves this behavior undefined.
所以这里至少有一个 "unwanted side effect"：即使只是尝试打开 FIFO 也可能会阻塞，除非您将 O_NONBLOCK 传递给 open() 调用（并打开它进行读取）。
那fcntl呢？正如 open(2) 手册页所指出的，要查看的部分是标题 "Mandatory locking" 和 "File leases"。在我看来 似乎 强制锁，在这种情况下，是一个转移注意力的问题，但是 - 它们只会在尝试实际读取或写入文件时导致阻塞：
If a process tries to perform an incompatible
access (e.g., read(2) or write(2)) on a file region that has an
incompatible mandatory lock, then the result depends upon whether the
O_NONBLOCK flag is enabled for its open file description. If the
O_NONBLOCK flag is not enabled, then the system call is blocked until
the lock is removed or converted to a mode that is compatible with
the access.
那么租约呢？
When a process (the "lease breaker") performs an open(2) or
truncate(2) that conflicts with a lease established via F_SETLEASE,
the system call is blocked by the kernel and the kernel notifies the
lease holder by sending it a signal (SIGIO by default). [...]
Once the lease has been voluntarily or forcibly removed or
downgraded, and assuming the lease breaker has not unblocked its
system call, the kernel permits the lease breaker's system call to
proceed.
[...] If
the lease breaker specifies the O_NONBLOCK flag when calling open(2),
then the call immediately fails with the error EWOULDBLOCK, but the
other steps still occur as described above.
好的，这是另一个不需要的副作用：如果您尝试打开的文件有租约，则 open() 调用可能会阻塞，直到租约持有人释放租约。
在这两种情况下，通过将 O_NONBLOCK 传递给 open() 而避免的 "unwanted side effect" 不出所料，open() 调用自身会阻塞，直到其他进程完成某些操作。如果您引用的手册页提到了任何 其他 种副作用，我不知道它们。
来自 Linux 系统编程，第 2 版，作者 R. Love（强调我的）：
O_NONBLOCK
If possible, the file will be opened in nonblocking mode. Neither the
open() call,
nor any other operation will cause the process to block (sleep) on the I/O.
This
behaviour may be defined only for FIFOs.
Sometimes, programmers do not want a call to read() to block when there is
no data
available. Instead, they prefer that the call return immediately,
indicating that no data
is available. This is called nonblocking I/O; it allows applications to
perform I/O, potentially
on multiple files, without ever blocking, and thus missing data available in
another file.
Consequently, an additional errno value is worth checking: EAGAIN.
请参阅内核邮件列表中的 this thread。
根据 man ioctl，使用 open 打开文件描述符可能会导致不需要的副作用。该手册还指出，以 O_NONBLOCK 开头可以解决那些不需要的问题，但我似乎无法找到原因是什么，也不知道实际的副作用是什么。有人可以阐明这一点吗？使用 ioctl 是否总是可以并等同于使用 O_NONBLOCK 打开文件描述符？
NOTES (from
man ioctl)In order to use this call, one needs an open file descriptor. Often the open(2) call has unwanted side effects, that can be avoided under Linux by giving it the O_NONBLOCK flag.
(* 我知道 O_NONBLOCK 意味着什么，但我不知道这是否会影响 ioctl 调用，就像影响其他系统调用一样。我的程序使用 ioctl 写入和读取 SPI 总线，在启用该标志的情况下完美工作。）
寻找答案的明显位置是 open(2) 手册页，在 O_NONBLOCK 的标题下，它说：
When possible, the file is opened in nonblocking mode. Neither the open() nor any subsequent operations on the file descriptor which is returned will cause the calling process to wait.
[...]
For the handling of FIFOs (named pipes), see also fifo(7). For a discussion of the effect of O_NONBLOCK in conjunction with mandatory file locks and with file leases, see fcntl(2).
好的，这不是很有用，但让我们点击链接，看看 fifo(7) 和 fcntl(2) 的手册页是怎么说的：
Normally, opening the FIFO blocks until the other end is opened also.
A process can open a FIFO in nonblocking mode. In this case, opening for read-only will succeed even if no-one has opened on the write side yet and opening for write-only will fail with ENXIO (no such device or address) unless the other end has already been opened.
Under Linux, opening a FIFO for read and write will succeed both in blocking and nonblocking mode. POSIX leaves this behavior undefined.
所以这里至少有一个 "unwanted side effect"：即使只是尝试打开 FIFO 也可能会阻塞，除非您将 O_NONBLOCK 传递给 open() 调用（并打开它进行读取）。
那fcntl呢？正如 open(2) 手册页所指出的，要查看的部分是标题 "Mandatory locking" 和 "File leases"。在我看来 似乎 强制锁，在这种情况下，是一个转移注意力的问题，但是 - 它们只会在尝试实际读取或写入文件时导致阻塞：
If a process tries to perform an incompatible access (e.g., read(2) or write(2)) on a file region that has an incompatible mandatory lock, then the result depends upon whether the O_NONBLOCK flag is enabled for its open file description. If the O_NONBLOCK flag is not enabled, then the system call is blocked until the lock is removed or converted to a mode that is compatible with the access.
那么租约呢？
When a process (the "lease breaker") performs an open(2) or truncate(2) that conflicts with a lease established via F_SETLEASE, the system call is blocked by the kernel and the kernel notifies the lease holder by sending it a signal (SIGIO by default). [...]
Once the lease has been voluntarily or forcibly removed or downgraded, and assuming the lease breaker has not unblocked its system call, the kernel permits the lease breaker's system call to proceed.
[...] If the lease breaker specifies the O_NONBLOCK flag when calling open(2), then the call immediately fails with the error EWOULDBLOCK, but the other steps still occur as described above.
好的，这是另一个不需要的副作用：如果您尝试打开的文件有租约，则 open() 调用可能会阻塞，直到租约持有人释放租约。
在这两种情况下，通过将 O_NONBLOCK 传递给 open() 而避免的 "unwanted side effect" 不出所料，open() 调用自身会阻塞，直到其他进程完成某些操作。如果您引用的手册页提到了任何 其他 种副作用，我不知道它们。
来自 Linux 系统编程，第 2 版，作者 R. Love（强调我的）：
O_NONBLOCK If possible, the file will be opened in nonblocking mode. Neither the open() call, nor any other operation will cause the process to block (sleep) on the I/O. This behaviour may be defined only for FIFOs.
Sometimes, programmers do not want a call to read() to block when there is no data available. Instead, they prefer that the call return immediately, indicating that no data is available. This is called nonblocking I/O; it allows applications to perform I/O, potentially on multiple files, without ever blocking, and thus missing data available in another file.
Consequently, an additional errno value is worth checking: EAGAIN.
请参阅内核邮件列表中的 this thread。