[ On Mon, June 24, 1996 at 11:19:24 (-0700), Bill Studenmund wrote: ]
> Subject: Re: tty0?
>
> Also, you have that process sitting around. Though it won't take up much
> space, it will take up some. Additionally, no such program or script is
> distributed with NetBSD.

You get what you pay for, in both respects.  In the latter case I think
one possible explanation is that it's just too trivial a problem to
worry about.  I've never found it any more difficult to use a one-line
shell script to do this:

	( stty 19200; while : do; sleep 32000; done ) < /dev/tty00 &

[modem control issues aside -- I still think you should physically wire
6+8+20 if you don't want modem control, and that the software should
always expect to work in full modem control mode, though there are most
definite advantages to the Sun scheme, except it means keeping locking
state in the kernel which is one of the most "dangerous" types of state]

I've probably typed a line like that more times than I care to remember,
but I have never found reason to complain about this, nor do I expect I
ever will.  A full-fleged program with a specific interface for this
purpose would probably save some bytes and be far more efficient, but I
don't know that I'd use it in favour of the shell script anyway.

> About keeping state in the kernel, my thought was to add an entry into the
> sysctl mib to handle changing the preference. I am willing to write code
> to do this (it's in the #2 slot in the to-do hopper). sysctl seems like a
> very good way to control a preference like this; you always have the
> program, you can find then desired entry easily, and the structure is read
> from routines in the running kernel (as opposed to frobbing w/ libkvm
> and kernel/user program sync problems).

I would rather it be a compile time option.  There are some tricky
issues that will be hard to get right in dealing with the change of this
meta state controlling state.  You will never be able to please all the
people all the time with a run-time option.  A compile-time option will
be Occam's Razor and cut to the chase of knowing the implications of the
decision you make when you configure your kernel.  Things won't suddenly
change underfoot of running processes, etc.  Predictability is good.

However, what I *really* meant by not liking the fact that state is kept
in the kernel is that I *really* don't like device drivers keeping
state.  Period.  They should always reset to a known state at some
predictable time, such as after the last close of the device file, or at
media change events, etc.  I don't like having to debug some strange
failure that's due to a sticky state in a driver that shouldn't be
sticky.  Those kinds of kernel bugs are *most* frustrating since they
are invisible and often undetectable as they have no different behavior
than normal operation under different external circumstances.

> My frustration with the traditional UNIX behavior is that it has one idea
> about what tty's are for. Everything's made for connecting people to the
> computer. Sure, other things are possable, like uucp-connectivity, slip
> and ppp, tablets, etc. But they are kinda tacked on top of connecting a
> person to the computer.

I don't think this is a philosophy based on what tty's are for.  It's
based on how software should interface to hardware, and on making
behaviour of devices predictable, and keeping interfaces simple and
elegant.  The difference may appear to be subtle, but it is extremely
important and fundamental to getting things "Right"(tm).

> Also, NetBSD and the other free UN*Xs are attracting a large batch of
> people who think about things differently. This thread was started when
> someone complained that his stty settings were disapearing. He expected
> that if he set something, it stuck. I certainly felt the same way when I
> got started with NetBSD. The traditional UN*X way (for this question) is
> just not what people expect. Reasonable for its origins, but not expected. 

People who get stuck with this idea are missing the whole point of
multi-processing systems.  They need to jump a meta-level before they'll
understand why things should not stick unless they nail them down.

I think it was the other way around when I first learned this trick.  It
was the gestalt I needed to push my understanding to the next level.
Living close to the hardware seems to make it hard to understand a more
generic point of view necessary for multi-processing and multi-user
operation.  I think I was beginning to write my first device driver for
Xenix at the time though, so I had an added depth of understanding at
that moment to help push me along.

> There is another way around this problem, which I mention to guage
> response. Resetting tty state on first-open would be fine if we could
> change these defaults. Right now, everytime you open a port, you get
> 7E1 defaults, with cannonical processing. All would be well if we just
> told people to "stty -d -f /dev/tty01 whatever" to change the defaults for
> the port. Thus getting the port into the state you want and having the
> defaults reset on each first open become two independent questions. I'd be
> willing to write code to do this also, if it would get seriously
> considered for inclusion.

There is ample precedent in the unix world for changing the first-open
defaults (or what they reset to after last close) for tty ports as you
describe, though I can't remember where I ran across it last (SCO? and
the digiboard driver for ISC).  I think later versions of POSIX might
have something to say about this too (hopefully they specify an
interface that would be useful).  I agree that 7E1 is not really
productive any more, and indeed picking the highest rational speed for a
device may also make more sense than 9600bsp or whatever.

Of course if you want to change all the global defaults you can always
change <sys/ttydefaults.h> and recompile the world, and hope for the
best! ;-)

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>