home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / minix / 5033 < prev    next >
Encoding:
Internet Message Format  |  1993-01-02  |  2.9 KB
  1. Path: sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!werple.apana.org.au!hal9000!monty!newton
  2. From: newton@monty.apana.org.au (Mark Newton)
  3. Newsgroups: comp.os.minix
  4. Distribution: world
  5. Subject: Re: minicom
  6. References: <1hre17INNcgl@werple.apana.org.au>
  7. Message-ID: <9301019220@monty.apana.org.au>
  8. Organization: APANA South Australia - State mail hub
  9. Date: Fri,  1 Jan 93 19:18:45 +1030
  10. Lines: 50
  11.  
  12. hock@werple.apana.org.au (Warwick Hockley) writes:
  13. > At the moment I can't even get login to work properly with a modem.  I have
  14. > to wait until the local modem has answered and hand shaking has taken place,
  15. > then kill login.  Init starts a new login, and this one works - ie, gives a
  16. > login message.  Everything is OK from there on.  But you can't take this 
  17. > seriously as a way to work.
  18.  
  19. Actually, answering the phone isn't login's job;  that task is supposed
  20. to be handled by getty.  By the time login starts up, the line should have
  21. been ioctl()'ed to the right baud rate, etc.
  22.  
  23. The problem is that the MINIX getty is woefully inadequate for the
  24. job (Sorry, Fred!  I'm not criticizing you, just your getty :-).  One
  25. would have thought that detecting the speed of an incoming modem
  26. connection was precisely the sort of thing that getty was supposed to
  27. do, but 1.5.10 getty hardly ever gets it right.
  28.  
  29. I believe the problem is in the detection of line breaks.  Sending
  30. a line break is easy (drop the baud rate to 300bps and send some nulls),
  31. but detecting an incoming line break is not really something that the
  32. MINIX kernel is very good at.  I am still critical of the standard
  33. getty despite the fact that it's the kernel's fault because getty 
  34. should have been designed to use something other than line breaks
  35. to detect the speed of incoming connections.
  36.  
  37. Before I set up my machine for public access, I spent a day or so hacking
  38. /real/ speed detection stuff into getty.  Now, if my getty is called with
  39. the -m flag, it sits on the line waiting for a CONNECT message.  When it
  40. finds it, it just reads the baud rate of the new connection straight from
  41. the serial port.
  42.  
  43. THIS WORKS, every time, without fail.  The line break solution basically
  44. never worked.
  45.  
  46. Now, why couldn't the original getty have been written like this, instead
  47. of depending on something as unreliable as line breaks for switching
  48. baud rates?
  49.  
  50. BTW, I acknowledge that my Amiga hardware will have a different rs232
  51. driver to the PeeCees, and that the PeeCee rs232 driver might be better
  52. at catching breaks.  If that is the case, then my criticism is undoubtably
  53. given from a 68000 bias, and should be read as such.  Warwick's comments
  54. tend to suggest that the intel boxes share the same problems, though.
  55.  
  56.    - mark
  57.  
  58. --------------------------------------------------------------------
  59. "Do not worry about an infinite            newton@monty.apana.org.au
  60. supply of gibbons..." - Al Dearle                        Mark Newton
  61. --------------------------------------------------------------------
  62.