Date: Mon, 24 Jul 1995 06:28:08 +1000 From: Bruce Evans <bde@zeta.org.au> To: ache@astral.msk.su, bde@zeta.org.au, terry@cs.weber.edu Cc: hackers@freebsd.org, harry@hgac.com, jkh@violet.berkeley.edu Subject: Re: dial up at > 9600 baud Message-ID: <199507232028.GAA21623@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>There's nothing really wrong with setting the initial speed to 38400
>>(except 38400 is too slow - why not 115200? :-). Use
>>`stty 115200 </dev/ttyid*' in /etc/rc.serial.
>Bruce, as I already says, I understand it, moreover, all ports
>works in that way on my site, but I was thinking that getty must be able
>to work right _without_ locked/initial devices settings too (see below).
It's not nice to have to specify the speed in more than one place, but
I regard that as a bug in getty or gettytab. getty thinks it owns the
line, but it doesn't if the dialout devices are used. gettytab is
unsuitable for general use. The database for the initial settings is
best maintained by the driver. We already have good access methods,
e.g., `stty -g' :-).
>>>I guess I still don't understand how the modem magically detects
>>>the port speed when the port sets the baud before it says anything
>>>(like "login: ").
>>Perhaps getty sometimes writes something before setting the speed.
>>It does quite a let between the open and setting the speed.
>I think that getty don't play role here. Most modern modems are
>able to sense local interface speed somehow, maybe initial
>connect handshake involved or other tricks, I don't know
>exactly.
It can't possibly depend on anything except signals on its RX line, and
getty is in complete control of those (unless there are bugs). I'm
assuming an external modem. For an internal modem emulating a 16x50,
the current 16x50 setting should apply.
>1) getty can't work right without setting
>of initial device, it is mandatory.
>So getty must open _initial_ device first (for serial lines only,
>for other lines normal device here),
>and setup all termios flags on it, then open normal
>device in blocking mode.
I don't like this. getty would also have to open the _lock_ device
to remove any locks (or perhaps to skip clobbering the initial state
if it is locked). The initial and lock devices are supposed to be
unknown to ordinary applications so that bugs in the applications
can be worked around and so that the applications don't become more
unportable.
>2) We additionly need to restore
>initial serial settings in sio.c in comhardclose(), i.e. call
>comparam(com->it_{in,out}) there.
>I plan to commit proposed changes in near future, if we agree.
I hope this is not necessary. Wait until I have committed lots of other
tty changes anyway. There are 5 currently h/w tty drivers and at least
3 more are scheduled, and only 2 of them even support initial state
devices :-(. The others normally inherit the speed from the previous
open, so it is more likely to be correct if only getty uses the line,
but certain to be incorrect (9600) for the first open and easier to mess
up if callout devices are supported.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507232028.GAA21623>