Hello,

I've been working with Gordon Ross on porting the machine-independent
z8530 driver to the mac-68k port. It's working well-enough that I
want to add some useful features to it. Some of these features
make use of unique hardware features of the mac, and others help
with MacOS compatability.

What I'd like is 9 numbers in the 't' hierarchy of ioctl's which
aren't being used and won't be used any time soon. I'm NOT asking
that these features be adopted as "the way things should be," just
that they are tolerated.

The concerned features are dealing with an external clock source
for the baud rate generator, and caching a copy of per-tty
personalized first-open attributes.

The functions needed (and tentative names) are:

TIOCCLOCKS	Get the number of clock sources this tty suports
TIOCGCLOCK	Get the clock rate of a clock source
TIOCSCLOCK	Set the clock rate of a source (if external)
TIOCGCLKSRC	Get which clock source is in use
TIOCSCLKSRC	Set which clock source to use

TIOCGDEFS	Get a copy of the current first-open termios for this tty
TIOCSDEFS	Set the current first-open termios for this tty
TIOCGUSEDEF	Get whether first-open defaults are being use on first-open
TIOCSUSEDEF	Set whether first-open defaults should be used on next
			first-open.

Note: I'm not asking that these definitions go into ttycom.h,
though that would be nice. They can live in a seperate file,
say dev/ic/z8530ttycom.h.

The first five routines let us set up an external clock source for
use by the tty port. Such a use would be VERY useful for MIDI adapters.
It is my understanding that present mac ones just give the computer an
external clock, set the baud rate generator, and thus send & receive
valid MIDI bytes. A few other ports (such as the atari) also support
multiple clock sources, so there's some use for integrating clock
sourcing into the M.I. 8530 driver.

The latter four routines are to better-support certain HP Deskwriters,
and to better-emulate how MacOS handles its serial ports.

The problem is that MacOS does not echo bytes received on the serial
port. Period. Upper layers of software will echo, but they have to
deliberately do the echoing. HP DeskWriter printers take this into
account and send status information to the host every 2 seconds.
MacOS will never echo these bytes back out. Nor should NetBSD.

Many people have suggested just having every application set the
terminal port to "raw" mode as soon as it opens the port. The real
problem is that there's a window in which echo is turned on. If a
byte is received in this window, it goes back out to the printer
and typically generates an ugly white-on-black (inverse printing)
'D'. I grant that this window will probably be small, but it's there.
I don't want to have to explain to people "I know MacOS never does
that, but NetBSD sometimes will." It just makes the printing not
reliable.

The other problem is that we get lots of UNIX novices in the mac-68k
port (which is cool). I forsee much dificulty with people getting these
ugly characters coming back out at the printer because they haven't set
the printer up right.

My experimental solution is to keep a termios struct in the softc
for the tty port, and to copy that termios to the tty termios
in a first-open situation. When the tty is attached, this termios gets
filled with all of the TTY defaults (TTYDEF_XFLAG, TTYDEF_SPEED,
ttychars, etc). If the port, or root, chooses to, these defaults
can get modified as desired. The code is written so if nothing is
done explicitly, the tty acts just like a TTYDEF should.

Note: I'm not wanting to suggest that other serial port drivers
should be modified to impliment this behavior. No, no, no, no.
I just want to make my printer work in a reliable and clean manner.

The latter two ioctls would determine if these defaults are copied on
first-open or not. Before you go complaining that "you should always
reset the defaults!" please note that many of the ports currently don't
reset the default values on first-open if there is a non-zero baud
rate. This behavior pre-dates my knowledge of NetBSD; I didn't tell
them they should do that. :-)

Some of these ports will hopefully use this code. For people to switch,
I think we need to be able to give them the exact behavior they had
before switching to the M.I. code. Since it's just a one-byte flag,
I don't see why we can't make it changeable.

I agree that many programs assume the defaults get reset. I agree that
not resetting the defaults can get people into trouble. I'm not saying
any other driver has to stop resetting the defaults. I'm just saying
that being able to have them linger can be a useful tool for debugging,
and it's easy. After all, one of the quotes I've heard (and lost the
originator of) that best describes UNIX's unbridled power-to-the-user
is that by letting you do stupid things, it also lets you do quite
clever things too. :-)

I've looked at all the ioctls defined in the current headers
(ttycom.h and ioctl_compat.h), and both 40 through 48, and 
say 140 through 148 are not in use. Would they be ok?

Thoughts?

Take care,

Bill