[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: 'getty' printing delay tokens in -current and netbsd-6
On Tue, Jun 26, 2012 at 09:59:09PM -0500, John D. Baker wrote:
> While transmitting a capability element that is supposed to indicate a
> delay is obviously wrong, performing actual NUL padding seems like a step
> backward to me. Is this what netbsd-5's (and earlier) getty did? If so,
> I was blissfully ignorant of this and it rather invalidates my concern.
NUL padding has been used for a long time.
Some bells in my head indicate it was used after <CR> and <LF> on
some systems that really did need delays.
(Like the DecWriter we had as the pdp/11 console.)
> Is it that much more complex to teach getty to honor delay attributes by
> actually waiting? (I know, I know, "So, where are your patches?".)
Actual delays are too hard - you need to wait for the fifo to drain
(or know how many bytes are in it), then wait the specified time.
That is two interrupts/callbacks and the timeout needs to be quite
> As to whether pad/delay is needed anymore, I have no doubt that someone,
> somewhere (such as myself) has one or more terminals where such attributes
> are relevant and will expect it to Just Work(tm) when he hooks it up
> rather than be Astonished by spurious output. (A friend has an ASR-33
> that we've been trying to get working again... ;)
Mmmmm 110 baud with remote echo over an acoustic coupled modem.
Both modems were in the same room, the error rate was too high
to make it useful!
David Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |