Werden Geräte-E / A auch dann gehandhabt, wenn ein Gerät von keinem Prozess geöffnet wird?

296
Julio Guerra

Die folgenden Shell-Programmbeispiele machen die Frage klarer.

Bei einem einfachen Zeichengerät (ein ftdi ttyUSB Gerät in meinem Fall), schicke ich es eine Anfrage mit echoan open();write();close();das Gerät, dann lesen Sie die Antwort mit catauf open();read();close();das Gerät, mit zwei unterschiedlichen Verfahren ( /bin/echound /bin/cat).

  1. Die folgenden Arbeiten:
$ /bin/echo -ne $request > /dev/ttyUSB0 ; /bin/cat -e < /dev/ttyUSB0  M-^?^B^@^C
  1. Folgendes funktioniert nicht:
$ /bin/echo -ne $request > /dev/ttyUSB0 ; sleep 2s ; /bin/cat -e < /dev/ttyUSB0  cat does not read anything
  1. Ein weiteres Arbeitsbeispiel:
$ /bin/cat -e < /dev/ttyUSB0 & sleep 2s ; /bin/echo -ne $request > /dev/ttyUSB0 M-^?^B^@^C

Was passiert in 2? Warum ist das Verhalten anders? Wohin sind die Daten gegangen?

1
Ihre Wahl der Verwendung eines Endgeräts (z. B. / dev / tty *) macht die Antwort komplizierter, da der Eingang des Terminals mehrmals gepuffert und stark verarbeitet wird (z. B. Leitungsdisziplin). Übrigens: Sie haben nicht angegeben, ob Sie einen Loopback-Jumper installiert haben. Die "Eingabe", die Sie "lesen", ist vermutlich ein vom Terminal-Subsystem erzeugtes lokales Echo (dh die Ausgabe wird nicht von der seriellen Schnittstelle empfangen). sawdust vor 8 Jahren 0
Die tty ist in meinem Fall auf nicht kanonisch eingestellt. Also kein Echo, keine Pufferung und keine Zeilenbearbeitung. Julio Guerra vor 8 Jahren 0
* "Das tty ist in meinem Fall auf nicht kanonischen Modus eingestellt. Also kein Echo." * - Die nicht kanonische Eingabe- und Ausgabeverarbeitung ist unabhängig von den Echoeinstellungen. * "... no buffering ..." * - Wenn Sie den Kernel-Treibercode tatsächlich studiert haben, werden Sie feststellen, dass dies eine lächerliche Behauptung ist. sawdust vor 8 Jahren 0

1 Antwort auf die Frage

1
David Schwartz

Die Daten gingen buchstäblich ins Leere. Niemand hat darauf gewartet, also wurde es verworfen. Die genaue Mechanik hängt von der Hardware ab. Normalerweise werden jedoch beim ersten Öffnen eines Geräts alle Empfangspuffer in der Hardware gelöscht. Es kann jedoch nicht garantiert werden, dass die Puffer überhaupt aktiviert sind.

Wie erklären Sie sich dann "1."? Die Reihenfolge der Syscalls ist dieselbe, aber ohne zu schlafen. Julio Guerra vor 8 Jahren 0
In Fall 1 wurden die Daten von der Hardware empfangen, nachdem das Gerät zum zweiten Mal geöffnet wurde. David Schwartz vor 8 Jahren 0
Es ist sinnvoll, da mein Gerät viel langsamer ist als die CPU. Gibt POSIX an, wie der Status der Gerätetransfers beim Öffnen aussehen soll? Ich versuche, laufende Anfragen von getöteten Prozessen (dh das Gerät antwortet) loszuwerden. Der Kernel empfängt auch dann noch Daten, wenn das Gerät geleert wird und dann Kernel-Fifos, was bedeutet, dass die Daten bereits vom Gerät gesendet werden und sich irgendwo im E / A-Baum befinden (USB-Gerät -> USB-Host -> PCI) ...). Ich bin schockiert, wie schwer es ist, eine Lösung für diesen sehr einfachen und gewöhnlichen Fall zu finden: Wie erhält man einen sauberen RX / TX-Gesamtzustand, sowohl SW als auch HW ... Julio Guerra vor 8 Jahren 0
Es ist sehr geräte- und protokollspezifisch. Wenn das Protokoll über eine Art Ping-Signal verfügt, das Sie senden können, können Sie auf eine Antwort warten und dann beide Enden synchron betrachten. Wenn nicht, können Sie eine Reihe von Dingen senden, die eine Antwort erhalten. Die Protokolldokumente sollten angeben, wie die Synchronisierung hergestellt wird. David Schwartz vor 8 Jahren 0

Verwandte Probleme