Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!mips!mips!sdd.hp.com!usc!sol.ctr.columbia.edu!destroyer!uunet!auspex-gw!guy From: guy@Auspex.COM (Guy Harris) Newsgroups: comp.unix.bsd Subject: Re: (386BSD) Modems and com ports Keywords: internal or external? Message-ID: <14226@auspex-gw.auspex.com> Date: 22 Aug 92 06:39:53 GMT References: <1992Aug20.171557.30071@watson.ibm.com> <1992Aug20.213721.4548@gateway.novell.com> Sender: news@auspex-gw.auspex.com Organization: Auspex Systems, Santa Clara Lines: 31 Nntp-Posting-Host: auspex.auspex.com >2) A UNIX write, once started, must run to completion before it may be > XOFed. In what sense? If the serial port device doesn't have DMA, and the main CPU hands it each character to be transmitted, one at a time, the driver can, if it receives a ^S, just stop handing the device characters until it gets a ^Q. If the serial port device *does* have DMA, then, if a DMA operation can be halt and restarted later, or can be aborted and restarted from where it left off, the driver can, if it receives a ^S, just halt or abort the transmission, and restart it when it gets a ^Q. Take a look at the VAX BSD DZ11 driver for an example of the former, and the VAX BSD DH11 driver for an example of the latter, if you have access to the source to those drivers. Other drivers that do the same can probably be found if you don't.... >The problem shared by any flow control whatsoever is lockup on line drop. >If the computer is ^s'ed, or !RTS or !CTS'ed, then the driver will wait >for the condition to be cleared. In most cases, this takes precedence >over a little thing like DCD dropping because of call waiting or a bad >connection. If so, the driver is probably buggy. It *should* manage - at least by default - to flush pending output, and wake up anybody waiting for the output queue to drain, if carrier drops. Some tty subsystems are buggy in that fashion, but it is a bug....