Re: 'getty' printing delay tokens in -current and netbsd-6

[David Laight <david%l8s.co.uk@localhost>]

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
fine grain!

> 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

-- 
David Laight: david%l8s.co.uk@localhost