Re: gnumach2 & the serial port

[Roland McGrath]

> I finally managed to get the sio driver from freebsd working with the
> gnumach kernel.  Was quite tricky to find the problems and the code is
> more or less a hack.  To fix the last we defently need a such a
> interface.  Here is my (first) attempt to such an interface.  Of
> course some more glue code is needed for this interface.

Nice work!  Can you show the code and say something about the problems and
hacks you had to do?

The serialdev interface is about the right level of abstraction, but I have
some different ideas about the details of the interface than what you've done.

oskit_device_t derivatives don't generally have control operations in their
direct interface.  Rather, their open method yields an object that has such
operations.  So, I think we want oskit_serialdev_t that has just an open
method and thus perhaps we can just use oskit_streamdev_t unmodified.  The
open method can produce objects that grok oskit_serialstream_t or such an
interface.  This then is the place for the modem control operationd and such.

The reason the interface is like this is so that "openness" can mean
something about the driver's state with respect to the hardware.  When you
have a handle on the device but have not called the open method, the
hardware might be turned off, needing reset, etc.  When you open it, it
will be catching the hardware interrupts, maintaining an input queue, etc.

There could reasonably be a single call to get/set the speed and other line
parameters like byte size and parity.  Might as well just be one, since the
underlying drivers we have are written with a single control interface anyway.

For fetching and changing the modem control bits, there should be just one
set of calls with a bitmask, i.e. equivalents to TIOCM* to set/clear some
or all bits.  

The main nonobvious thing we need is an interface for being notified on
modem status changes.  A simple thing is just to support asyncio and report
"exceptional conditions" on a modem status change.  So the caller wakes up
and calls read_modem_control or whatever it is to see what's happened.
Another idea is to structure it so that state transitions are never lost.
i.e., each change in the modem control bits is a event that is queued like
a byte of input.  I haven't decided whether it seems important to have an
interface that won't drop past states if there are multiple state changes
before the caller gets around to polling after a notification.  

Another question is synchronization of status changes with input.  I've
been saying "modem control changes", but really I am talking about all the
out-of-band information the device has to report.  This includes
e.g. hardware-detected parity errors.  For those, the user (i.e. the Hurd
terminal server) needs to get the parity-error event in the proper order
with respect to the good bytes that arrived before and after it.  So you
need the interface for reading bytes to interact with the status reporting.
e.g., read a packet of bytes + status info instead of just stream-reading;
or, having stream_read block (return EAGAIN or another error for this case)
until you've polled for status information.