Date: Wed, 7 Jun 1995 01:15:10 +1000 From: Bruce Evans <bde@zeta.org.au> To: bugs@FreeBSD.org, pete@pelican.com Subject: Re: TTYHOG still... Message-ID: <199506061515.BAA15476@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>PLEASE PLEASE (OK, wait for release, maybe, but it is impossible to run
>uucp on a fast link as things are) fix TTYHOG to be an option:
A ttyhog variable would be better.
>(or *better*, fix the real problem and make clist sizes dynamic; it is
>ridiculous to make interactive opens have 16k ttyhog just to get uucp
>to work on a single port.)
Send code.
>At 1024 I can sometimes get errors just from chat setting up a slip call.
>Yes, I have crtscts set and it does work. I still get the ****** ttyhog
>error message.
That means crtscts doesn't really work.
>Related to this:
>***FLAME ON:
>Also, don't insist in the man page and rc.serial that setting crtscts
>is an application responsibility; it isn't. It is a hardware
Er, you seem to have interpreted the sio man page backwards. It is
mostly about setting up the ports outside of applications (see termios.4
for application programming). It tells you when to set CRTSCTS (...
should be locked _on_ for ...). This is mixed up a bit with a gripe
about buggy applications. The buggy applications gratuitously clear
CRTSCTS, so it should be _locked_. But locking gets in the way of
applications that actually handle CRTSCTS correctly. Handling of
locking is even less of an application responsibility.
>to everything, even the shell and 'cat', for several. The init+lock
>device is the right thing, only it is documented rather negatively. The
>application (in this kind of case) has *no business whatever* knowing what
>kind of device is connected; it only knows about data streams.
>***FLAME OFF
Well, the point of the init+lock device _is_ mostly negative:
lock device: entirely negative:
(N1) fixes CLOCAL security hole.
(N2) helps fix buggy applications that gratuitously change implementation-
defined state that they don't know about.
init device: positive:
(P1) allows setting good initial values for implementation-defined state
that most applications don't know about.
init device: negative:
(N3) helps fix buggy applications that don't set standard state.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506061515.BAA15476>