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