Carrier-Lost Signal vom Treiber
Martin Husemann
Hallo!
Da ist eine Sache, die ich einfach nicht ganz verstehe (ich debugge immer
noch meinen absolut-perfekten-seriellen-Treiber):
Wenn ein Programm vom Treiber ein Signal fuer "DCDlow" anfordert,
merkt der Treiber (ALLE die ich bisher gesehen habe) sich die pid
des anfordernden Prozesses.
Wird das Modem aufgelegt, sendet er EIN Signal an den LETZTEN Prozess,
der dieses angefordert hat. Alle anderen gehen leer aus.
Ein Beispiel: ich benutze mmon, mmenu, elm und nn. Ueber das Menue bin ich
in NN gelangt, dort schreibe ich mit Mikro-Emacs einen Artikel (so wie
jetzt). Da stolpert meine Frau ueber die per Freihandverdrahtung verlegte
Telefonleitung und reisst den Stecker raus. Carrier weg, Modem's legen auf.
Der Treiber sendet ein Signal an ME, der bricht ab und beendet ohne zu
speichern, NN uebernimmt wieder die Kontrolle und fragt, ob ich den
Artikel wegwerfern, editieren oder verschicken moechte. NN bekommt KEIN
Signal, und merkt also auch nicht, dass ich gar nicht mehr da bin.
Ebenso ergeht es MMENU und MMON.
Das ganze passiert so oder aehnlich regelmaessig. Meist nicht mir selbst,
aber ich bin nach dem CONNECT schon so ziemlich als beliebiger User im
System gewesen.
Wie sollte das denn theoretisch ueberhaupt funktionieren? Ist das ein
Implementierungsfehler in ELM, NN, MMENU oder MMON? Ist das ein Fehler
im Treiber (dann sollte man MW davon erzaehlen!) Oder ist das alles
ein Gedankenfehler von mir?
Gruss, Martin.
Fnord!
Ulrich Dessauer
m.husemann@itb_box.north.de (Martin Husemann) writes:
[..]
~ Wenn ein Programm vom Treiber ein Signal fuer "DCDlow" anfordert,
~ merkt der Treiber (ALLE die ich bisher gesehen habe) sich die pid
~ des anfordernden Prozesses.
~
~ Wird das Modem aufgelegt, sendet er EIN Signal an den LETZTEN Prozess,
~ der dieses angefordert hat. Alle anderen gehen leer aus.
Genau in diesem Punkt sehe ich das Problem. Das Signal sollte
nicht an den letzten Prozess gesendet werden, sondern an den ersten,
der es angefordert hat. Sollte danach ein anderer Prozess das Signal
anfordern, dann sollte der Treiber beim I$SetStt eine -1 zurueck-
liefern. So ist dann sichergestellt, dass der Prozess, der das Signal
anfordert, das auch (hoffentlich) richtig behandelt.
In der beschriebenen Kombination waere `mmon' der Prozess,
der das Signal bekommt; er wuerde dann allen Kindprozessen ein
Signal schicken und auf deren Terminierung warten.
Eine andere Loesung auf Treiberebene: Der Treiber sendet
jedem Prozess, der einen Pfad auf dieses Device geoeffnet hat ein
Hangup Signal.
Any Comments?
Gruss, U//i
--
Ulrich Dessauer, +49 89 841 78 11, u...@nitmar.ddt.sub.org
Wolfgang Ocker
In article <P*@nitmar.ddt.sub.org> u...@nitmar.ddt.sub.org (Ulrich Dessauer) writes:
~Hallo,
~m.husemann@itb_box.north.de (Martin Husemann) writes:
~~ Wenn ein Programm vom Treiber ein Signal fuer "DCDlow" anfordert,
~~ merkt der Treiber (ALLE die ich bisher gesehen habe) sich die pid
~~
~~ Wird das Modem aufgelegt, sendet er EIN Signal an den LETZTEN Prozess,
~~ der dieses angefordert hat. Alle anderen gehen leer aus.
Der Treiber sollte beim Erkennen eines Hangups die Variable
V_Hangup auf 1 setzten. Der Scf liefert dann bei jedem weitern
Zugriff auf das Device einen Fehler (E$HangUp).
Beste Gruesse,
/// Wolfgang
Josef Wolf
] Ein Beispiel: ich benutze mmon, mmenu, elm und nn. Ueber das Menue bin ich
] in NN gelangt, dort schreibe ich mit Mikro-Emacs einen Artikel (so wie
] jetzt). Da stolpert meine Frau ueber die per Freihandverdrahtung verlegte
] Telefonleitung und reisst den Stecker raus. Carrier weg, Modem's legen auf.
] Der Treiber sendet ein Signal an ME, der bricht ab und beendet ohne zu
] speichern, NN uebernimmt wieder die Kontrolle und fragt, ob ich den
] Artikel wegwerfern, editieren oder verschicken moechte. NN bekommt KEIN
] Signal, und merkt also auch nicht, dass ich gar nicht mehr da bin.
] Ebenso ergeht es MMENU und MMON.
Normal sollte das Signal an den mmon gehen, der dann den anderen
Prozessen je ein SIGHUP schickt, und wenn sie nach einger gewissen Zeit
noch laufen, brutal killt. Frueher ging das bei mir auch einwandfrei.
Aber jetzt hab ich beim mmon scheinbar was falsch eingestellt, so dass
das nur noch ab und zu geht. Ansonsten der von Dir beschriebene Fall.
Wer hat eine Idee, welchen Parameter ich da falsch eingestellt haben
koennte?
] Das ganze passiert so oder aehnlich regelmaessig. Meist nicht mir selbst,
] aber ich bin nach dem CONNECT schon so ziemlich als beliebiger User im
] System gewesen.
_Das_ sollte natuerlich nicht sein, denn: wenn der mmon noch der Meinung
ist, da waere ein User online, dann sollte das Modem natuerlich nicht so
initialisiert sein, dass es abheben koennte.
Gruss
Sepp
| Josef Wolf, Germersheim, Germany | +49 7274 8047 -24 Hours- (call me :-) |
| se...@ppcger.ppc.sub.org | +49 7274 8048 -24 Hours- |
| ...!ira.uka.de!smurf!ppcger!sepp | +49 7274 8967 18:00-8:00, Sa + Su 24h |
| Die Welt ist schoen, so schoen! | all lines 300/1200/2400 bps 8n1 |
| Was ich nicht weiss, macht mich nicht heiss. Drum bleib ich immer heiter! |
Martin Husemann
>] Das ganze passiert so oder aehnlich regelmaessig. Meist nicht mir selbst,
>] aber ich bin nach dem CONNECT schon so ziemlich als beliebiger User im
>] System gewesen.
>_Das_ sollte natuerlich nicht sein, denn: wenn der mmon noch der Meinung
>ist, da waere ein User online, dann sollte das Modem natuerlich nicht so
>initialisiert sein, dass es abheben koennte.
Hmm - und wie macht man das? Aus anderen Programmen kenne ich die Variante,
dass "MMON" erst auf die RING-Meldung vom Modem hin ein "ATA" schickt.
Aber es ist mir noch nicht gelungen, das bei mmon zu konfigurieren. So
habe ich das Modem auf Auto-Answer stehen, und es hebt natuerlich immer
ab, wenn DTR an ist.
Ansonsten habe ich inzwischen die Variante von Ulrich Dessauer eingebaut,
das klappt jetzt schon ganz hervorragend. Ich werde auch noch V_Hangup
setzen und dann mal schauen.
Gruss, Martin.
Fnord!