目标是“locking”对串行设备或其他Linux设备的访问，以确保在设备正在使用时对其进行独占访问。 这可以防止例如两个程序打开相同的串行设备，并“竞争”从设备读取字节。
build议一直使用SYSV风格的UUCP设备locking文件，如/var/lock/LCK..ttyS1 。 这是Linux串行HOTWO推荐的：locking其他 。 它也logging在Filesystem Heirarchy标准中 。 它是由串行terminal程序如gtkterm，picocom实现的。 有liblockdev和liblockfile这样的库来支持这个（尽pipe这两个库的实现细节有所不同）。
不过，我发现Debian bug＃734086 ，在Linux上说，不推荐使用SYSV风格的UUCP设备锁，而应该使用flock()咨询锁。
然而，我找不到一个可靠的文档来源来描述这些SYSV风格的UUCP设备锁的弃用，以及flock()build议，而不是Debian的bug本身。
我还发现了screen工具用来lockingterminal的ioctl(fd, TIOCEXCL) 。
Linux中locking串口和其他设备的现代“最佳实践”是什么？ 我们在哪里可以find描述这个的最新文档？
据我所知，使用串行端口或其他设备的flock()锁定可能是Linux中最好的方法，在Debian的bug＃734086之后 。 请注意，这个Debian变更的原始倡导者Roger Leigh已经在2014/2015年从Debian和Linux迁移到了FreeBSD（见他的评论 ）。 但Debian似乎坚持flock()方法，所以这是值得的。
然而，鉴于这一改变已经传递给了更广泛的Linux社区，在这种情况下支持旧的SYSV型UUCP设备锁定文件（ /var/lock/LCK..ttyS1 ）作为编译时选项，用于仍然使用旧锁方法的系统。
例如picocom现在已经改为使用flock()方法，编译时可选择SYSV样式的UUCP设备锁定文件。
我想就此提交一份关于串行HOWTO的更新（因为它是“Linux串行锁”的第一个谷歌搜索结果），但现在由于其当前的维护状态而很难在LDP网站上更新文档。