问题描述
目标是锁定"对串行设备或其他 Linux 设备的访问，以确保在设备正在使用时对其进行独占访问.例如，这可以防止两个程序同时打开同一个串行设备并竞争"从该设备读取字节.
The goal is to "lock" access to a serial device or other Linux device, to ensure exclusive access to the device while it's in-use. This prevents, for example, two programs both opening the same serial device and "competing" to read bytes from the device.
建议使用 SYSV 样式的 UUCP 设备锁定文件，例如 /var/lock/LCK..ttyS1.这就是 Linux Serial HOWTO: Locking Out Others.文件系统层次标准中也记录了它.由 gtkterm、picocom 等串口终端程序实现.有 liblockdev 和 liblockfile 来支持这个(尽管这两个库的实现细节不同).
The advice has been to use SYSV-style UUCP device lock files such as /var/lock/LCK..ttyS1. That is what is recommended by Linux Serial HOTWO: Locking Out Others. It is also documented in the Filesystem Heirarchy Standard. It is implemented by serial terminal programs such as gtkterm, picocom. There are libraries such as liblockdev and liblockfile to support this (although the implementation details differ between these two libraries).
但是，我发现 Debian 错误 #734086，这在 Linux 上说，不推荐使用 SYSV 样式的 UUCP 设备锁，并且 flock() 应该使用咨询锁.
However, I have found Debian bug #734086, which says on Linux, SYSV-style UUCP device locks are deprecated, and flock() advisory locks should be used instead.
但是，除了 Debian 错误本身之外，我找不到可靠的文档来源来描述这些 SYSV 样式 UUCP 设备锁的弃用以及 flock() 的推荐.
However, I can't find a reliable document source to describe deprecation of these SYSV-style UUCP device locks, and recommendation of flock(), other than that Debian bug itself.
我还发现 ioctl(fd, TIOCEXCL) 被 screen 实用程序用来锁定终端.
I've also found ioctl(fd, TIOCEXCL) which is used by the screen utility to lock a terminal.
在 Linux 中锁定串行端口和其他设备的现代最佳实践"是什么?我们在哪里可以找到描述此内容的最新文档?
Which is the modern "best practice" for locking serial ports and other devices in Linux? Where can we find up-to-date documentation describing this?
推荐答案
据我所知，使用 flock(fd, LOCK_EX | LOCK_NB) 串行端口或其他设备的锁定可能是 Linux 中最好的方法，继 Debian 在 Debian 错误 #734086.请注意，这次 Debian 变更的最初倡导者 Roger Leigh 已在 2014/2015 年从 Debian 和 Linux 转向 FreeBSD(参见 他在这里的评论).但是 Debian 似乎坚持使用 flock() 方法，所以这是值得的.
As far as I can tell, using flock(fd, LOCK_EX | LOCK_NB) locking of serial ports or other devices is probably the best the way to go in Linux, following Debian's lead in Debian bug #734086. Note that the original advocate of this Debian change, Roger Leigh, has moved away from Debian and Linux and onto FreeBSD in 2014/2015 (see his comments here). But Debian seems to be sticking with the flock() method, so that's worth something.
但是，鉴于此时此更改与更广泛的 Linux 社区的沟通非常糟糕，支持较旧的 SYSV 样式 UUCP 设备锁定文件(/var/lock/LCK..ttyS1) 作为编译时选项，用于仍在使用旧锁定方法的系统中.
However given how poorly this change has been communicated to the broader Linux community at this point, it could be good to support the older SYSV-style UUCP device lock files (/var/lock/LCK..ttyS1) as a compile-time option, for use in systems still using the older lock method.
例如picocom 现在已更改为使用 flock() 方法，其中SYSV 样式 UUCP 设备锁定文件的编译时可选选择.
E.g. picocom has now changed to using the flock() method, with a compile-time optional selection of SYSV-style UUCP device lock files.
StackOverflow 上的另一个答案 描述了两种方法:
ioctl(fd, TIOCEXCL)flock(fd, LOCK_EX | LOCK_NB)方法
它说一个应用程序可以选择做一个，或两个"，进一步解释:
It says "An application can choose to do one, or both", further explaining:
同时使用两者的原因是为了检测另一个进程是否已经打开了设备而不将其置于独占模式，但希望设置了咨询锁.在这种情况下，open() 和 ioctl() 都成功了，但 flock() 失败了.
The reason to use both, is to detect if another process has already opened the device without putting it into exclusive mode, but has hopefully set the advisory lock. In that case, the
open()andioctl()both succeed, but theflock()fails.
因此，值得另外实现 ioctl(fd, TIOCEXCL).
So, it is worth implementing ioctl(fd, TIOCEXCL) additionally.
这篇关于在 Linux 中锁定串行端口和其他设备的最佳做法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2