On Sun, 23 Jun 1996, Greg A. Woods wrote:

> [ On Sat, June 22, 1996 at 16:06:32 (-0700), Bill Studenmund wrote: ]
> > Subject: Re: tty0?
> >
> > I think the best answer is that it should be changable; YOU decide what
> > YOU want YOUR system to do. For a multi-person, or a production system, it
> > makes sense to reset defaults after each close. Conversely, on my system
> > at home, when I'm debugging talking to my DeskWriter, I want to stty some
> > settings and have them stay. Using some #%*&&*#$ port-holding program
> > seems frustrating and silly. 
> 
> What, pray tell, is the difference between setting a flag in the driver
> (and providing it the means to save state on a per-device basis),
> vs. running a simple user-level utility?
> 
> I can tell you two real differences.  One is that the user-level utility
> is somewhat simpler, far more elegant, and much much easier to debug.
> It doesn't require state to be kept in the kernel where it's difficult
> to discern.  On the other hand, the user-level utility "breaks" some of
> the other normal port control behaviour, since now a process always has
> the device open -- this may be a good or bad thing depending on what
> you're trying to do.

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.

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).

> > So I vote it's changable. On a per-tty basis.
> 
> I'd strongly prefer to see traditional UNIX behaviour here.  I have some
> minor recollection that POSIX.? or X/Open has something to say about
> this though, and I would defer to either (though I hope they agree if
> they both have something to say about it).

I'm not trying to suggest that we disallow traditional behavior, just that
you can change the behavior if you want. And if you're root. :-) So if the
machine's acting non-POSIX-ish, it's because of root. Principle of least
supprise dictates that the default is to be POSIXish (reset defaults on
first open).

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.

This philosophy certainly made sense 10 or 15 years ago, and still makes
sense for large machines, where lots of people modem into a command shell,
or have/had a direct-connected terminal. But a large fraction (most?) of
the machines running NetBSD today don't really fit this description. I
think most people either sit at, or telnet to, the NetBSD machine they
use. Serial lines get used either for mice, modems to dial up ISP's, or
printers.

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. 

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.

These ideas aren't "traditional BSD," but wasn't part of the traditional
behavior that BSD soaked up good ideas from elsewhere and made them
better?

Take care,

Bill