Date: Sun, 23 Jul 95 17:24:44 MDT From: terry@cs.weber.edu (Terry Lambert) To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka) Cc: bde@zeta.org.au, hackers@freebsd.org, harry@hgac.com, jkh@violet.berkeley.edu Subject: Re: dial up at > 9600 baud Message-ID: <9507232324.AA03440@cs.weber.edu> In-Reply-To: <dVKif4myC0@astral.msk.su> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka" at Jul 23, 95 10:55:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. This is critically bogus unless you cn back this up with documentation on external clock signal support. The modem must interact with the computer to sense the port speed. Period. If getty is spitting crap out before setting the port speed, then that is a getty problem, and should be fixed. But anything else (with the possible exception of waiting on RI instead of DCD and timing out on a baud rate non-read) *will* break bidirectional use of the port *and*should*not*be*allowed*. > I plan to rewrite getty to open device > as non-blocked first, set up all termios flags (not speed only > can play role on intelligent multipord card), then open > device in blocked mode (wait for carrier). But in one moment > I realize that while getty waits for carrier, some other > dialout application can become active and leave serial speed > into unpredictable state. It's also broken because the wait for DCD on the blocking open is only in effect when the open count is 0. After one open as a non-blocking open, the reference count is one, and subsequent opens are not *supposed* to block. So what you want to do *will not work* anyway. You need to find out why the modem believes the port is being locked to 9600, why the modem can't be locked to a higher rate anyway instead of doing the "auto-sense" BS, how the "auto-sense" you postulate could possibly be happeneing (if you're right), and whether the getty incorrectly spits crap at the port before setting the baud, and whether the port incorrectly fails to discard input prior to DCD coming high. > I plan to commit proposed changes in near future, if we agree. PLEASE think this through in terms of the finite state automatons for the modem, getty, and the serial driver. You are engaged in protocol modifications! Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9507232324.AA03440>