home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / bsd / 4571 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  1.8 KB
  1. Path: sparky!uunet!auspex-gw!guy
  2. From: guy@Auspex.COM (Guy Harris)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: (386BSD) Modems and com ports
  5. Keywords: internal or external?
  6. Message-ID: <14226@auspex-gw.auspex.com>
  7. Date: 22 Aug 92 06:39:53 GMT
  8. References: <1992Aug20.171557.30071@watson.ibm.com> <1992Aug20.213721.4548@gateway.novell.com>
  9. Sender: news@auspex-gw.auspex.com
  10. Organization: Auspex Systems, Santa Clara
  11. Lines: 31
  12. Nntp-Posting-Host: auspex.auspex.com
  13.  
  14. >2)    A UNIX write, once started, must run to completion before it may be
  15. >    XOFed.
  16.  
  17. In what sense?
  18.  
  19. If the serial port device doesn't have DMA, and the main CPU hands it
  20. each character to be transmitted, one at a time, the driver can, if it
  21. receives a ^S, just stop handing the device characters until it gets a
  22. ^Q.
  23.  
  24. If the serial port device *does* have DMA, then, if a DMA operation can
  25. be halt and restarted later, or can be aborted and restarted from
  26. where it left off, the driver can, if it receives a ^S, just halt or
  27. abort the transmission, and restart it when it gets a ^Q.
  28.  
  29. Take a look at the VAX BSD DZ11 driver for an example of the former, and
  30. the VAX BSD DH11 driver for an example of the latter, if you have access
  31. to the source to those drivers.  Other drivers that do the same can
  32. probably be found if you don't....
  33.  
  34. >The problem shared by any flow control whatsoever is lockup on line drop.
  35. >If the computer is ^s'ed, or !RTS or !CTS'ed, then the driver will wait
  36. >for the condition to be cleared.  In most cases, this takes precedence
  37. >over a little thing like DCD dropping because of call waiting or a bad
  38. >connection.
  39.  
  40. If so, the driver is probably buggy.  It *should* manage - at least by
  41. default - to flush pending output, and wake up anybody waiting for the
  42. output queue to drain, if carrier drops.
  43.  
  44. Some tty subsystems are buggy in that fashion, but it is a bug....
  45.