Subject: per-port settable tty defaults
To: None <tech-kern@NetBSD.ORG>
From: Bill Studenmund <email@example.com>
Date: 08/28/1996 22:23:01
Me again. :-)
For a number of reasons (some having to do with the way HP DeskWriters
behave), I'd like to see per-port tty defaults in NetBSD.
I am willing to write patches to add this functionality.
I want to first propose my idea, and get suggestions on how to do it
better (or possably find out everyone hates the idea, and my diff's
will just go into the bit bucket, in which case I won't make them). :-)
The basic idea is to add an extra termios to struct tty, and move the
termios setup which is in all the open routines to the attach routine
(setting up the new termios), leaving the open routine to just bcopy
the defaults termios to the current-settings termios.
1) The defaults will be set by doing an "stty -D whatever" (rather than
having a seperate device whose settings are the default for the tty),
which would use two new IOCTL's to get and set the defaults. I think
libc would have to gain two new lib routines as wrappers for the
2) Move the code which reads the TTYDEF_[CILO]FLAG defaults to somewhere
in the attach code (I've got somewhere in mind, but EXACTLY where can
be cahnged), and set the defaults termios up rather than t_termios.
3) tty drivers which support settable defaults just change their open
code to bcopy the defaults over. Some drivers won't do this as they
are either for dedicated hardware (like console keyboards, etc), or
they are ptys, for which variable defaults would be a mess.
4) ttioctl gets support for an ioctl to get the defaults termios, and
to set the default termios to the current settings.
The last little trick reflects the fact that NetBSD only has one
routine per tty which validates the tty settings, t_param, which also
sets the hardware to these settings. I don't think adding another
parameter to t_param is worth it, nor do I think setting the port
defaults to unrealizable settings is wise. The only case where the
difference shows up is if the port is in use when you try to set the
defaults, and the defaults differ from the present settings. Otherwise,
there's no difference.
My thought on where to add the defaults initialization is to tty_malloc
(though the init. could go somewhere else). My thoughts are that
tty_malloc does more than just allocate space, it sets the tty up for
use by allocating the input and output queues. Setting the defaults up
here fits in with the idea of "setting the tty up." And it means the
drivers don't need to worry about the defaults.