Re: term & user space console

[Roland McGrath]

I think Thomas gave you the information you needed, but just to throw a few
things in.

The hurdio bottom half should use the very same term/tioctl interfaces that
term implements for users to diddle the underlying state.  It should be
fairly obvious from how term uses the bottom_half functions what tioctl
calls they translate into.  The modem twiddling calls pretty much go
directly.  For set_bits, I think you can do:

        tioctl_tiocgeta (underlying, &ttystat);
        if (termstate.__ispeed)
          ttystat.__ispeed = termstate.__ispeed;
        if (termstate.__ospeed)
          ttystat.__ospeed = termstate.__ospeed;
        cfmakeraw (&ttystat);
        ttystat.c_cflag = termstate.c_cflag &~ HUPCL;
        tioctl_tiocseta (underlying, &ttystat);
        
Of course, check for errors and if you get EOPNOTSUPP or MIG_BAD_ID
from tiocgeta, then don't try the set calls.

What's questionable to me is some of the funny modes like IGNBRK/BRKINT and
PARMRK.  I guess parity can just be done in term, but it seems desireable
to pass it down.  I think we don't pass it down now in devio because the
Mach drivers do bogus stuff.  But it is ultimately desireable to have the
parity setting passed down all the way to the hardware and have some
reasonable way for term to grok that a parity error came from below.
Likewise for detecting breaks (munge.c:input_break is never called right now),

Incidentally, if you're cleaning things up, I think most or all the
bottom_half routines should be able to return errors.  That is certainly
useful for all the ones that are implemented with RPCs.  Currently devio
does not check for errors at all, which is not good.  Errors that are not
MIG_BAD_ID/EOPNOTSUPP should be reported upwards (any tioctl might
reasonably result in EIO, e.g. when the UART has caught fire).

As to the term.defs interfaces, most of those have never been implemented
or used.  So don't read too much into that.  I think we should GC all these
never-real calls from the term interface whenever we feel like it.  The
"get_bottom_type" and so forth is a narrower version of the whole
libchannel library and get_channel_info RPC concept I've described before.
The existing devio and pty types don't implement those interfaces either.
For now, you can add the hurdio type to main similar to the existing ones.