Subject: Re: tty0?
To: NetBSD <>
From: Greg A. Woods <>
List: current-users
Date: 06/24/1996 23:21:30
[ On Mon, June 24, 1996 at 22:55:01 (-0300), wrote: ]
> Subject: Re: tty0?
> Tell this to the guys at BSDI. I am quite sure they DO understand what 
> multi-user, multi-processing systems are!

The BSDI folks have been known to put only three legs on the corners of
a square table before because of customer demand.  The customer is not
always right, but when he's paying you let him think so.  I hope the
"free" *BSDs never fall into that trap.

Now, I'm not saying this particular case matches the scenario I paint.
In fact you've not described exactly what's happening at a sufficient
level of detail to know what's going on here.

Perhaps you are mistaken and are really thinking of the BSDI-1.1
'-D' extension to the stty command:

     -D      Display or set the system default settings rather than those for
             the current device.  The system defaults are used when a device
             is initially opened.  The system defaults may be set only by the

I've only access to BSDI-1.1 kernel source (i.e. not stty(1)), so I'm
not sure exactly how this is accomplished.  The tty subsystem in
BSDI-1.1 is quite a bit different in some respects to the NetBSD one,
and I can't quite see where it might be setting and storing these
defaults.  The kernel source seems to ignore <sys/ttydefaults.h> too,
except in one driver (si).

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

Well, yes, to a certain degree.  Some programs aren't quite so careful
as to completely reset all possible values to a known state, and indeed
may not be aware of some extensions available on some systems.  These
are the cases where stuck, invisible, state is most horrible.

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

I didn't disagree with the concept of allwoing the default state to be
set, and given what the BSDI-1.1 manual pages suggest, this would be an
extension to the POSIX standard:

     The stty function is expected to be IEEE Std1003.2 (``POSIX'') compati-
     ble.  The -e and -D options are extensions to the standard.  The slip,
     tty and flushout keywords are extensions to the standard.

In this case I would suggest following BSDI's lead.

							Greg A. Woods

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