On Mon, 24 Jun 1996, Greg A. Woods wrote:

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

True. :-)

> In the latter case I think
> one possible explanation is that it's just too trivial a problem to
> worry about.

Then maybe put a mention of the issue, and a sample script, in the stty
man page. Right now, you have to run into the problem and then ask what's
wrong to find out. If it were in the man page, then it's a RTFM. :-)

> [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]

Hmm. I'm not familiar with "the Sun scheme," but I think requiring
software to always work in full modem control mode is a bit rigid. I'd
prefer flexability. I use NetBSD because it lets my mac do what _I_ want,
not what the programmer wanted.

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

I can see an advantage to fixing some options at compile time, but I tend
to prefer to permit a lot of changes to happen at run time. I like the
sysctl idea as, among other things, it lets me (or you if you come in to
fix my broken computer) find out what's set how. I like how AIX can keep a
lot of its configuration in its ODM. Many things are dynamically
modifyable. I'm not suggesting we add an ODM, but I like flexability.

Also, for the mac68k port, we have a lot of users who can't compile
kernels. Things are changing enough as it is (giving us lots of test
kernels, etc.) that being able to change some kernel options on the fly
really helps.

In this case, I don't think there would be any problems with behavior
changing under a process's feet; either the tty is open, or closed. This
question only applies to what happens during open. Though I could see a
problem if we changed other parameters (but for ttys, stty takes care of
them now).

[comments about what users/new admins expect]

> 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 guess that comment strikes at part of what's changing. I definitely
agree that a multi-user system sould reset hardware state. But NetBSD, and
the other fre UN*X's are becoming popular single-user multi-processing
systems. I'm trying to nudge us towards better accomodating such
situations _in_addition_to_ supporting multi-processing and multi-user
operation.

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

Part of my frustration comes from the reaction I got months ago when I
mentioned such things on tech-kern. The reaction I got was mostly "That's
the way UNIX does it." I also got (mostly) negative reactions to trying to
add configurable defaults.

I think the resetting of defaults at first open would become much less an
issue if we actually had modifiable defaults. 

My strong feelings on this matter come from the fact that I have a
DeskWriter printer. It's way of sending status to the mac is to send a
status character every 2 seconds. So there's this continuous data stream
to the computer. MacOS does not default to echoing, but NetBSD does. So if
I boot NetBSD with the printer on, I get a whole bunch of ugly black
characters at the top of the page. Even with an stty -f /dev/tty01 raw in
/etc/rc.local, I get characters on the page (booting takes a while on
POKEY :-)

My fix has been to add modifyable defaults to the zstty driver, and to add
a (machine dependent) hack that sets these defaults to "raw" mode if
requested by the MacOS Booter.

Take care,

Bill