Subject: Re: tty0?
To: Greg A. Woods <firstname.lastname@example.org>
From: NetBSD <email@example.com.UnB.br>
Date: 06/24/1996 22:55:01
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:
stty -f /dev/tty00 back-to-original-defaults-flag
stty -f /dev/tty00 special-program-flags
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!