andrew@frip.gwd.tek.com (Andrew Klossner) (04/27/88)
[]
"It's my understanding that getty implements break detection in
a very straightforward way: Any ASCII null ('\0') will cause
getty to toggle to the next baud rate. (The idea is presumably
that a break will appear as nulls with framing errors at any
baud rate; attempting to actually detect the framing error
would involve fooling with BRKINT, which means getty would have
to catch a signal, and then you have the old
second-signal-too-fast-ain't- catchable bugaboo under pre V.3
System V.)"
The idea actually was to support old simple serial ports that didn't
have break or framing error detection. These ports responded to break
or framing error by appearing to receive a null; the software had no
way to tell the difference between a break and receipt of a legitimate
null.
Getty and its human interface are a lot older than post-v7 tty driver
features like BRKINT. In the bad old days there was no way to send a
signal in raw mode (other than by unplugging the terminal to drop
carrier).
"Suppose getty gets a null as a garbage character -- such as
when a terminal is turned on or a PC being used as a terminal
is rebooted. Is getty smart enough to understand that it
doesn't really have to change speed from 9600 to 9600?"
No, it will do a new ioctl (and a new spin loop, counting from 0 to
65535) (under system V release 3). But a "smart" serial port driver
shouldn't reprogram the UART on an ioctl if the baud rate hasn't really
changed. (Perhaps not all drivers are "smart.")
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]