steve@nuchat.UUCP (Steve Nuchia) (11/16/89)
Recently I have found myself writing about the two-inode method of handling bidirectional serial ports, which I believe is a relatively recent innovation (3-4 years?), and didn't know who should get the credit for it. The method is outlined below. I have used it in all my serial drivers since I encountered in in Microport 286 Unix. It is supported now in most 386s, SunOS, and some others, but many boxes don't have it (A/UX for one) and some of those who do don't document it well. My question is, who thought it up? Any historical notes appreciated, but I don't think simple "sighting reports" should be posted. Mail me any from say '86 or earlier. The method is to allocate one or more bits in the minor device number for the serial ports to control some aspects of the line. These aspects are often wired in as extensions to termio if not as minor device bits. As was the case with tape devices in the early days, the problem with this is that not all the software you want to use with a port knows about the extensions or has ways to administer the settings. It can be argued that certain serial port settings are logically system configuration options rather than application options. While this can be taken too far, it is often useful to think of hardware handshaking configuration this way. The system admin sets up the /dev entry to have the right bits based on the characteristics (and settings) of the attached peripheral, and the application can and should ignore those aspects of the connection. I've used two mode bits, one to enable DCD/DTR modem control and another to enable some form of hardware flow control. Exactly which form depends on the traditions of the shop the driver is for (what we really need is a standard for serial communications :-). When modem control is used one arranges two names for each physical port, analogous to the rmt0,nrmt0 stuff with tapes. Some naming convention is necessary, take for instance /dev/ttym0 for outdial and ttyM0 for indial. The upper case M would signify the "modem control" bit set. The driver enforces the following policies: At most one logical device may be open for any one physical port at a time. Attempts to open an outdial port currently open for indial will fail (EBUSY suggested) Attempts to open an indial port currently open for outdial will block in open. Attempts to open an indial port not currently open will block in open until DCD is asserted. Blocked attempts will not prevent outdial opens. If DCD is lost while open for indial, take action as local policy or termio settings indicate -- send SIGHUP, cause reads to return 0, whatever seems right. There may be an exact answer to this but I haven't found it. DTR is asserted while the port is open and while any open attempt is blocked. It is deasserted otherwise, and is deasserted for 1/2 second when the driver close routine is called. This allows modems that support the feature to reset or at least hang up. This combination of policies means that getty and uucico can share a line with very little interference and no silly uugetty games. The only complications are a races involving calls arriving while uucico has the line open but on hook and the fact that uucico isn't prepared for EBUSY. There is no fix for the first problem, though having your Devices file run in reverse order through your hunt group helps. The second problem causes uucico to give up if it tries a busy line even though there may be lines available. This is not often noticed by sites with few lines. The solution is to have getty craft a lock file for the corresponding outdial line when its open on the indial line returns, and to clear the corresponding lock when it restarts. Getting this right is a little subtle, I've got code (nasty but working) if anyone wants it. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "Man is still the best computer that we can put aboard a spacecraft -- and the only one that can be mass produced with unskilled labor." - Wernher von Braun
jfh@rpp386.cactus.org (John F. Haugh II) (11/17/89)
In article <16497@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >My question is, who thought it up? Any historical notes appreciated, >but I don't think simple "sighting reports" should be posted. Mail >me any from say '86 or earlier. I recall TRS-Xenix having this feature as far back as 1984 or so. I don't have my TRS-Xenix manuals out right now, but I can look it up if anyone is really interested. -- John F. Haugh II +-Things you didn't want to know:------ VoiceNet: (512) 832-8832 Data: -8835 | The real meaning of IBM is ... InterNet: jfh@rpp386.cactus.org | ... I've Been to a Meeting. UUCPNet: {texbell|bigtex}!rpp386!jfh +--<><--<><--<><--<><--<><--<><--Yea!--
arun@photon.tamu.edu (Arun Madhwesh) (11/21/89)
Hi Yih-Farn, Thanks for replying to my query! Yes, I would very much like to get a copy of gr2ps. Is it possible to send it via email or can I ftp it from your machine? Where was it developed in Berkeley? My email address arun@cssun.tamu.edu or arun@photon.tamu.edu. My ph# is (409)-845-8752. Let me know if you need anything. In re your question, yes, Dr John Yen joined A&M this fall and his email address is yen@cssun.tamu.edu. Thanks again for your offer, Arun Madhwesh