> 
> > Note: I'm not wanting to suggest that other serial port drivers
> > should be modified to impliment this behavior. No, no, no, no.
> 
> I'd say that TTY ioctls that are "device-independent", e.g. the one
> for setting the default termios state, either: 
> 	(1) should be implemented for all drivers (preferably in a
> 	    driver-independent way, but that's another story), or
> 	    at least should be "to be be implemented" for all drivers,
> 	(2) if there isn't good enough reason to have it implemented
> 	    for all, it should not be implemented for any.
> 
> Don't waste time implementing some set of weird 'machine-dependent'
> ioctls on one driver, and not another; if the feature is _needed_ (and
> i'm not at all convinced that your 'default termios state' features
> _are_ really needed, but probably could be), then it'll be needed in
> other drivers, too.

I think I agree with your points.  I'll agree that most people probably
won't need to change the defaults on a tty port. But I do think that
some sort of per-port personality is needed (for the DW at least),
and that it's much better to change the personality at run time (either
config, or true running) than at compile time. Since changing on the
fly is easy (it's just a bcopy), why not?

I think that doing this in a driver-independent fashon would be best.
But that there's inertia in these matters, and that this driver
might be a place to start. Changing the drivers to work this way
is really easy; a new struct termios needs to be added somewhere,
code often now in open() moves to attach(), and a bcopy goes into
open() (in the driver routines). If people wanted, I could even
be talked into generating diffs for this change. :-)

> > 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.
> 
> What did A/UX do?  NetBSD/mac68k is much, much more like A/UX than it
> is like MacOS.
> 
> I would be very surprised if it behaves differently than NetBSD's
> current behaviour, w.r.t. echo.  In fact, i think i'd be so surprised
> that i'd ask the person who said that it did (if anybody does) what
> settings, exactly, they used in NetBSD and in A/UX, and i'd pull my
> mac out of the closet, boot it into A/UX (which, along with the
> necessary small MacOS partition is the only OS installed), and try it
> out.

I'm not sure what A/UX did, though didn't A/UX kinda die about the
time DeskWriters became popular? The DW came onto the scene in 90-91,
and the PPC agreement w/ Apple was in the summer of 91. I gathered
(I could be wrong) that A/UX didn't get much attention after that,
giving a slow and lingering death.

NetBSD is way differnt from MacOS (Yes!), but this printer was designed
for an environment w/o echoes. It's like a precocious child, speaking
when not spoken to, and acting regrettably when actually being spoken
to (printing these characters). It's kinda like this beast needs a
different line discipline; it acts differently than a terminal. But
adding another line discipline when the only problem is the defaults
from opening is silly, and too much work.

Other serial printers don't have this problem. My EPSON FX (Oooo
I'm dating my teen-age years now!), when hooked to my Tandy CoCo
didn't send anything back to the printer. The StyleWriter only
speaks when spoken to (quite possibly because of A/UX). But, well, mine
is not so civil. :-(

Also, what are the thoughts about the external clock stuff? Only
drivers which support external clock sources should do anything,
but I was hoping for a (possibly different from what I described)
way of, "If you do this, do it this way." ??

Take care,

Bill