Re: term & user space console

[Thomas Bushnell, BSG]

Roland McGrath <roland@gnu.org> writes:

> 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),

This is all true.  The problem is that Mach's device interface sucks,
and doesn't export what we need; still, the only place that is visible
is in devio.c.  Everything else is designed with the intention of a
fully working implementation.

> 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).

In principle, I agree.

> 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.
> http://mail.gnu.org/mailman/listinfo/bug-hurd

Agreed.