Ich weiß, dass die Datei /dev/ptmxzum Generieren einer Masterdatei für ein Pseudoterminal verwendet wird. Ich habe jedoch herausgefunden, dass Fedora eine andere ptmxDatei hat ( /dev/pts/ptmx):
Was ist der Zweck dieser zweiten Datei?
Antwort1
Der Grund liegt, wie bei vielen Dingen in der Computerwelt, in der Geschichte und der Abwärtskompatibilität.
In den 2.4.*-Kerneln, bevor udev(die aktuelle virtuelle Dateisystemlösung für /dev) in Linux existierte, gab es zwei konkurrierende Lösungen: die „traditionelle Unix-Methode“, bei der sich die Geräte in einem realen Verzeichnis auf einem Root-Dateisystem befanden, und devfs, die erste virtuelle Dateisystemlösung für /dev.
Das Problem bestand darin, dass der Autor von devfsein völlig neues Benennungsschema für verschiedene Geräte entwickelt hatte und die Leute ziemlich starke Gefühle dagegen hatten: Einige wollten auf das neue Schema umsteigen und das alte abschaffen, andere sahen keine Notwendigkeit für eine Migration. Einige Distributionen verwendeten die alten statischen Geräte, andere wählten devfs.
Zu diesem Zeitpunkt wurde bei der Installation eine feste Anzahl von Pseudo-TTY-Geräten erstellt. (Das ist übrigens immer noch möglich, wenn die CONFIG_LEGACY_PTYSOption beim Kompilieren Ihres Kernels festgelegt wird.)
Dann wurden dynamisch zugewiesene PTY-Geräte im Unix98-Stil eingeführt. Die Implementierung in einem statischen /devVerzeichnis erforderte ein virtuelles Dateisystem für /dev/pts, und dies wurde als Dateisystem bezeichnet . Hätte man dies als separates Dateisystem gehabt, wäre es wahrscheinlich auch möglich gewesen, es ohne Code-Duplikation devptsauf das dynamische anzuwenden .devfs
Die dynamisch zugewiesenen PTY-Geräte wurden schnell zur bevorzugten Wahl, da es /deveindeutig unsinnig war, das System mit Hunderten von statisch zugewiesenen PTY-Geräten vollzustopfen, von denen die meisten während der gesamten Lebensdauer des Systems möglicherweise nie verwendet würden.
Dann kam Linux 2.6 und udevmit ihm. Es machte sowohl die statischen /devals auch devfsdie Lösungen schnell obsolet. Aus Gründen der Abwärtskompatibilität devptsexistierte das Dateisystem noch, aber jetzt konnte die gleiche Funktionalität zurück auf das Hauptdateisystem verschoben werden /dev, da es jetzt vollständig RAM-basiert war.
Heute beispielsweise mountet Debian 9 devptsdas Dateisystem noch /dev/ptsaus Gründen der Legacy-Kompatibilität, weist aber /dev/pts/ptmxstandardmäßig keinerlei Berechtigungen zu – dies ist ein Zeichen dafür, dass das devptsDateisystem wahrscheinlich veraltet ist und zu einem späteren Zeitpunkt entfernt wird.
# ls -l /dev/ptmx /dev/pts/ptmx
crw-rw-rw- 1 root tty 5, 2 Nov 22 11:47 /dev/ptmx
c--------- 1 root root 5, 2 Nov 12 14:59 /dev/pts/ptmx
Wenn ein Programm noch immer benötigt /dev/pts/ptmx, kann dies durch Anpassen der Standardberechtigungen zugelassen werden. Dadurch erfahren die Benutzer jedoch, welche Programme noch immer den älteren, veralteten Gerätenamen verwenden.
Antwort2
Wenn ein Prozess /dev/ptmx öffnet (mitposix_openpt()), erhält es einen Dateideskriptor für einen Pseudoterminal-Master (PTM) und ein Pseudoterminal-Slave-Gerät (PTS) wird im Verzeichnis /dev/pts erstellt.
Wenn der Master geöffnet wird, ist der Slave gesperrt. Sie können den Namen des Slaves abrufen, seine Berechtigungen usw. festlegen und den Slave dann entsperren. Dies ermöglicht die Kontrolle über den Slave, bevor er zugänglich ist.
Der Slave emuliert ein echtes Textterminalgerät, der Master stellt die Mittel bereit, mit denen ein Terminalemulatorprozess den Slave steuert.
Der Slave ist eine virtuelle Implementierung eines physischen Terminals und der Master ist eine virtuelle Implementierung der menschlichen Tipparbeit auf diesem Terminal. Der Computer behandelt an den Slave gesendete Zeichen so, als hätte ein Mensch sie auf einem realen Terminal eingegeben (eingeschränkt durch die Berechtigungseinstellungen bei der Erstellung des Masters).