>    I'm lucky in that I'm
>    writing the serial port driver, so each serial port is gaining the
>    ability to have its own concept of tty defaults.
> 
> If you do that, I will personally shoot you.  Having different drivers
> interrupt the APIs differently is *extremely* bogus.      

Perhaps I mis-spoke. AFAIK, the API is the same. The private data
structure for each tty has its own cflag, iflag, lflag, and oflag
defaults. At attach, TTYDEF_[CILO]FLAG gets copied to this value.
Also, the "do we always reset the defaults on first open" flag gets
set in a machine-dep part of the code. So with no intervention by root,
these defaults (== TTYDEF_XFLAG) get imposed upon the port. The code
works just like you described it should, right out of the box.

However I've added 3 new ioctl's (and I'm unsure how to define their
exact numbers). One sets the "do we always reset the defaults on first
open" flag, one clears it, and one copies the current settings from
the tty to the private [cilo]flag values. You have to be root to use
these ioctl's.

I've tried to only add to the interface, and make it so that either
the port maintainer, the kernel compiler, or root has to take a
deliberate action to get non-standard behavior. But if they want it,
they get it.

>    Also, I agree that it's dangerous for a program to assume a tty will be
>    just as it needs it, but what do we do for programs which can't set
>    tty settings right?
> 
> You fix the program.  In the case of lpd, in particular, this is quite
> trivial.

I haven't hacked on lpd, so I'm at the base of the learning curve.
How do I fix it?

I think the real fix would be to add a new entry to printcap. If this
field's present, stty gets forked on the output port & sent the flags in
this element. Some form of unix (Linux?) does this; Ghostscript's
default printcap entry contains such a field. So instead of cryptic
bit settings which require perusal of header files, we say something
like "57600 raw crtscts clocal".

> Now, it has occured to me (and I believe I've even suggested) changing
> `ttyflags' to allow specifying a full set of default control modes for
> each tty.  That would seem to be a more general and more useful way of
> solving the echo problem.

I think such a change would be a Good Thing, but how do we deal with the
few characters which might get echoed between when the tty gets defined
(and we start being able to echo) and when we get to ttyflags?

Hmm. Or are the iflags supposed to be 0 at that point. Would that
give us echo, or no echo? My NetBSD is at home.

Take care,

Bill