Re: Sio & Puc memory mapped

On Sun, 16 May 2004, Marcel Moolenaar wrote:

> On Sun, May 16, 2004 at 10:01:18PM +1000, Bruce Evans wrote:
> >
> > *snip*.  The only fundamentally broken thing in the uart driver's
> > defaults is that they have echos enabled, so an echo war results if 2
> > ports driven by the uart driver are connected and one of them happens
> > to send a character before an ioctl can be done to set a useable state.
>
> The uart(4) driver uses TTYDEF_xFLAG from <sys/ttydefaults.h>
> Are the TTY defaults in that header wrong or are those merely a
> good general set of defaults that one may need to tweak in ones
> particular case (e.g. depending on the device or depending on
> the open mode)?

They are essentially a good set of defaults for interactive shells,
or almost equivalently, for getty(8) and init(8).  Note that init(8)
knows noththing about termios.  It just opens _PATH_CONSOLE and does
i/o to it.  Thus console drivers must do the same termios initialization
that getty would do by default, so that the single user shell doesn't
have a surprising termios state.  Similarly, shells don't touch most
of the termios state.  They mostly just do i/o to open file descriptors
supplied by their parent.  Changes to the whole state are usually done
using stty(8).  E.g., "stty sane" sets to almost the defaults given
in <sys/ttydefaults.h>.  Not so similarly, syslog(3) and syslogd(8)
know nothing about termios.  They just open _PATH_CONSOLE and write
to it.  Thus they depend on some of the driver's defaults (only the
ones that affect output) like init(8).  The driver's defaults need to
be programmable at runtime so that the state for syslog* can be changed.
They are essentially a good set of defaults for interactive shells,

They are a bad set of defaults for terminal programs and most test
programs.  Only the issue with echo is critical.  Terminal and test
programs can handle noise from bogus echoes at the cost of extra
complexity, but whatever they are connected to might not.  Perhaps
this was more of an issue on old slow systems with buggy drivers that
didn't discard input on open.  The echo war could take almost 100%
of the CPU so many characters could be echoed before an ioctl could
be run to kill the echoes.

Bruce