Re: term & user space console

[Thomas Bushnell, BSG]

Roland McGrath <roland@gnu.org> writes:

> > This is all true.  The problem is that Mach's device interface sucks,
> 
> What interface would you like for this (parity and break reception)?  It
> seems to me that either you need to have a general way to return
> out-of-band exceptional data events (that are sequenced with regular data),
> or else have it implement something like the PARMRK behavior that you can
> filter the data for.

For breaks, I would like something akin to pty packet mode.  On each
read, the first byte says whether it's real data or rather an error.
To give the right semantics, you shouldn't successfuly read a break
until after the break has actually terminated.  (Because a single
break of however long [assuming it isn't so long the modem hangs up]
should generated only one signal or other indication.)  Similarly,
framing errors would be indicated by such a status byte.  I guess that
means there would be three values.

All input parity checking is done by term itself, and the device
should just do none (or at least provide a way to turn it off).

Output parity bits should be added automatically by the lower half as
a consequence of a devio_set_bits call for which CIGNORE was not
specified.  It should be possible to change the byte size, number of
stop bits, speed, and whether a parity bit is added.  Mach allows only
setting the speed.  It allows only 8N output, and only the normal stop
bit convention.

Any integer should be allowed as a speed.  Rejection of unsupported
speeds should happen *only* in the actual physical device handler,
because only it knows what is possible for that UART.

It should be possible to cause breaks of arbitrary duration (hence the
set_break and clear_break calls).  

Of course, complete access should be given to all the modem lines.
Handling of wait-for-carrier and stuff is done in Unix by the kernel,
and (unfortunately) in the Mach drivers; we want it done in term,
which is already set up to DTRT.

Thomas