2015-05-19 11 views
5

Das Ziel ist es, den Zugriff auf ein serielles Gerät oder ein anderes Linux-Gerät zu "sperren", um exklusiven Zugriff auf das Gerät zu gewährleisten, während es gerade verwendet wird. Dies verhindert beispielsweise, dass zwei Programme das gleiche serielle Gerät öffnen und "konkurrieren", um Bytes von dem Gerät zu lesen.Was ist die beste Vorgehensweise zum Sperren serieller Ports und anderer Geräte in Linux?

Der Ratschlag, SYSV-style UUCP-Gerätesperrdateien wie /var/lock/LCK..ttyS1 zu verwenden. Das wird von Linux Serial HOTWO: Locking Out Others empfohlen. Es ist auch in der Filesystem Heirarchy Standard dokumentiert. Es wird von seriellen Terminalprogrammen wie gtkterm, picocom implementiert. Es gibt Bibliotheken wie liblockdev und liblockfile, um dies zu unterstützen (obwohl die Implementierungsdetails zwischen diesen beiden Bibliotheken unterschiedlich sind).

Allerdings habe ich Debian bug #734086 gefunden, die unter Linux sagt, SYSV-Stil UUCP Gerät Sperren sind veraltet, und flock() Advisory-Sperren sollten stattdessen verwendet werden.

Ich kann jedoch keine zuverlässige Dokumentquelle finden, um die Ablehnung dieser SYSU-ähnlichen UUCP-Gerätesperren und die Empfehlung flock() zu beschreiben, abgesehen von diesem Debian-Fehler selbst.

Ich habe auch gefunden ioctl(fd, TIOCEXCL), die von der screen Dienstprogramm verwendet wird, um ein Terminal zu sperren.

Welches ist die moderne "Best Practice" zum Sperren serieller Ports und anderer Geräte in Linux? Wo finden wir eine aktuelle Dokumentation, die das beschreibt?

+0

Ich sehe, dass dies eine enge Abstimmung wegen der "in erster Linie auf der Meinung der Meinung" getroffen hat. Aber damit die Sperrung der seriellen Schnittstelle mit UUCP-Sperrdateien oder 'flock()' funktionieren kann (beide sind "beratend"), ist es wichtig, dass alle Programme dieselbe Methode verwenden, sonst funktioniert die Sperrung nicht. Z.B. Wenn ein Programm UUCP-Dateisperren benutzt und ein anderes Programm 'flock()', dann ist das Sperren unwirksam und beide können den Port öffnen. Das ist also eine pragmatisch wichtige Frage, um einen Konsens in der Linux-Community zu erreichen. –

Antwort

1

Soweit ich das beurteilen kann, ist die Verwendung von flock() Sperren von seriellen Ports oder anderen Geräten wahrscheinlich der beste Weg in Linux zu gehen, nach Debians Führung in Debian bug #734086. Beachten Sie, dass der ursprüngliche Befürworter dieser Debian-Änderung, Roger Leigh, 2014/2015 von Debian und Linux auf FreeBSD gewechselt ist (siehe his comments here). Aber Debian scheint mit der flock() Methode zu kleben, also ist das etwas wert.

Allerdings, wie schlecht diese Änderung an die breitere Linux-Community zu diesem Zeitpunkt kommuniziert wurde, könnte es gut sein, die älteren SYSV-Stil UUCP Geräte-Lock-Dateien (/var/lock/LCK..ttyS1) als eine Kompilierzeit-Option für den Einsatz in Systeme, die immer noch die ältere Sperrmethode verwenden.

z. picocom wurde jetzt geändert, um die flock()-Methode zu verwenden, mit einer optionalen Kompilierungsauswahl von SYSV-style UUCP-Gerätesperrdateien.

Ich möchte diesbezüglich ein Update zum Serial HOWTO einreichen (da es das erste Google-Suchergebnis für "Linux Serial Lock" ist), aber momentan ist es schwierig, Dokumente auf der LDP-Website zu aktualisieren Wartungszustand.

Verwandte Themen