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

[ text deleted ...]

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

Tell this to the guys at BSDI. I am quite sure they DO understand what 
multi-user, multi-processing systems are!

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

I have not been using NetBSD for too long, but I am not new in the unix 
world. I have been using BSDI's unix for quite some time and, hey, when I 
do an 'stty -f /dev/tty01 clocal' on BSDI's boxes it sticks. Both BSDI and 
NetBSD being derived from the same 4.4BSD source, I thought that was 
supposed to be the correct behavior for ALL 4.4BSD derived systems.

By the way, if your program is to be portable, and you know that some 
systems reset to a known default state on open and others don't you'll 
end up writing code to reset a tty to a known state, to be sure it works 
on both. The same code would also work on a machine with run-time 
changeable defaults, of course.

I tend to agree with Bill most of the time. Why not add the flexibility 
of changing the defaults at run-time? If someone wants to be sure that 
the system is on a predetermined state, just change it to that state. You 
would have to open and close the device to be sure, anyway.

Wouldn't it be nice to do something like this:

#!/bin/sh
stty -f /dev/tty00 back-to-original-defaults-flag
run-the-program

or

#!/bin/sh
stty -f /dev/tty00 special-program-flags
run-the-special-program

If the program assumes nothing about the state of the tty it wants to open 
(supposedly simpler) it'll work. If it knows who it is dealing with, then 
the stty's above are not necessary, but harmless.

I know that if the default behavior is to reset the tty on 
first-open/last-close then you could get the same results by keeping the 
port open before the stty.

What's the real difference? Also, will this change make it harder for the 
user, the developer of the OS, both, or none?

Any change that may make the user's life easier (without much change for 
the developer) should be received with open arms!

Regards