Roland McGrath <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
