Date: Mon, 24 Jul 1995 01:20:00 +0400 (MSD) From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka "Andrey A. Chernov, Black Mage" <ache@astral.msk.su> To: 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: <dV0qh4muA4@astral.msk.su> In-Reply-To: <199507232028.GAA21623@godzilla.zeta.org.au>; from Bruce Evans at Mon, 24 Jul 1995 06:28:08 %2B1000 References: <199507232028.GAA21623@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199507232028.GAA21623@godzilla.zeta.org.au> Bruce Evans
writes:
>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 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.
I agree with it too, it is just different strategy.
My proposal #1 from previous message replaces with following one:
1) Initial devices should be documented in
getty/gettytab manpages as mandatory to obtain working serial getty.
(I can't do it by myself due to my english).
My proposal #2 from previous message _still_active_:
>>2) We additionly need to restore
>>initial serial settings in sio.c in comhardclose(), i.e. call
>>comparam(com->it_in) there.
>>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.
I mean external modem too. So only initial connect handshake left for
speed determination (getty not control it at all :-)
>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.
Right now I not plan to make any tty or getty changes, just one neccessary
change in comhardclose(): add comparam(com->it_in) there, do you agree
with that?
--
Andrey A. Chernov : And I rest so composedly, /Now, in my bed,
ache@astral.msk.su : That any beholder /Might fancy me dead -
FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead.
RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dV0qh4muA4>