在Linux中锁定串口和其他设备的最佳实践是什么？

Question

其目标是“锁定”对串行设备或其他Linux设备的访问权限，以确保在使用中时对设备的独占访问。例如，这样可以防止两个程序打开同一个串行设备，并“竞争”从设备读取字节。

建议使用SYSV风格的UUCP设备锁文件，如/var/lock/LCK..ttyS1。这是Linux串行HOTWO:将他人拒之门外推荐的。它也被记录在文件系统传家宝标准中。它由串行终端程序(如gtkterm、picocom )实现。有像liblockdev和liblockfile这样的库来支持这一点(尽管这两个库之间的实现细节不同)。

然而，我发现了Debian bug #734086，它说在Linux上，SYSV风格的UUCP设备锁是不推荐的，应该使用flock()建议锁。

但是，除了Debian本身之外，我找不到一个可靠的文档源来描述这些SYSV风格的UUCP设备锁和flock()的推荐。

我还找到了ioctl(fd, TIOCEXCL)，screen实用程序使用它锁定终端。

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

Answer 1

据我所知，在Linux中使用flock(fd, LOCK_EX | LOCK_NB)锁串行端口或其他设备可能是最好的方法，就像Debian在Debian bug #734086中的领先。请注意，Debian更改的最初倡导者Roger已经从Debian和Linux转移到了2014/2015年的FreeBSD (参见他在这里的评论)。但是Debian似乎坚持使用flock()方法，所以这是值得的。

然而，考虑到这一改变在这一点上传达给更广泛的Linux社区是多么糟糕，最好支持旧的SYSV风格的UUCP设备锁文件(/var/lock/LCK..ttyS1)作为编译时选项，以便在仍然使用旧锁方法的系统中使用。

例如，皮科姆现在改为使用flock()方法，在编译时可选SYSV风格的UUCP设备锁文件。

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

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

它说，“一个应用程序可以选择一个，或两者”，进一步解释：

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

因此，另外实现ioctl(fd, TIOCEXCL)是值得的。