在Linux中锁定串行端口和其他设备的最佳做法是什么？

Question

目标是"锁定"对串行设备或其他Linux设备的访问,以确保在设备正在使用时对设备进行独占访问.例如,这可以防止两个程序打开相同的串行设备并"竞争"从设备读取字节.

建议一直使用SYSV风格的UUCP设备锁文件等/var/lock/LCK..ttyS1.这就是Linux Serial HOTWO推荐的:Locking Out Others.它还记录在Filesystem Heirarchy标准中.它由gtkterm,picocom等串行终端程序实现.有库,比如liblockdev和liblockfile支持这个(尽管实现细节这两个库之间的差异).

但是,我发现Debian bug#734086,在Linux上说,SYSV风格的UUCP设备锁已被弃用,flock()应该使用咨询锁.

但是,我找不到一个可靠的文档源来描述这些SYSV式UUCP设备锁的弃用,以及flock()Debian bug本身以外的推荐.

我还发现实用程序ioctl(fd, TIOCEXCL)使用哪个screen锁定终端.

在Linux中锁定串口和其他设备的现代"最佳实践"是什么？我们在哪里可以找到描述这个的最新文档？

Answer 1

据我所知，在Debian bug #734086flock(fd, LOCK_EX | LOCK_NB)中，使用锁定串行端口或其他设备可能是 Linux 中最好的方法。请注意，这一 Debian 变更的最初倡导者 Roger Leigh 已于 2014/2015 年从 Debian 和 Linux 转向 FreeBSD（请参阅此处他的评论）。但 Debian 似乎坚持使用这种方法，所以这是值得的。flock()

然而，考虑到目前这一更改与更广泛的 Linux 社区的沟通情况很差，最好支持旧版 SYSV 风格的 UUCP 设备锁定文件 ( )/var/lock/LCK..ttyS1作为编译时选项，以便在仍然使用旧版的系统中使用。锁定方法。

例如，picocom现在已更改为使用该flock()方法，并在编译时可选地选择 SYSV 样式的 UUCP 设备锁定文件。

StackOverflow 上的另一个答案描述了两种方法：

1. ioctl(fd, TIOCEXCL)
2. 方法flock(fd, LOCK_EX | LOCK_NB)​

它说“应用程序可以选择执行其中一项或两项操作”，并进一步解释：

使用两者的原因是检测另一个进程是否已打开该设备而不将其置于独占模式，但希望设置了咨询锁。在这种情况下，open()和ioctl()都成功，但flock()失败。

因此，值得ioctl(fd, TIOCEXCL)额外实施。