From owner-freebsd-hackers Sun Jul 23 13:35:13 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id NAA12215 for hackers-outgoing; Sun, 23 Jul 1995 13:35:13 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id NAA12203 for ; Sun, 23 Jul 1995 13:35:06 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA21623; Mon, 24 Jul 1995 06:28:08 +1000 Date: Mon, 24 Jul 1995 06:28:08 +1000 From: Bruce Evans Message-Id: <199507232028.GAA21623@godzilla.zeta.org.au> To: ache@astral.msk.su, bde@zeta.org.au, terry@cs.weber.edu Subject: Re: dial up at > 9600 baud Cc: hackers@freebsd.org, harry@hgac.com, jkh@violet.berkeley.edu Sender: hackers-owner@freebsd.org Precedence: bulk >>There's nothing really wrong with setting the initial speed to 38400 >>(except 38400 is too slow - why not 115200? :-). Use >>`stty 115200 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