Hi Wagi, > > > 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. > > Looking at the asyncio interface the first thing would be covered > 'naturally' by it. It depends if dropping state changes is important > or not. I try to figure it out by looking how other system handle it. >
For modem changes the async I/O exception could be used. The user would then have to do a special status read. It's probably useful to queue all changes, perhaps with a timestamp. Come to think of it, maybe we should do the same for the control lines. Ie. you write a struct which contains a timestamp, an operation (xor, or, and, set) and a bitmask. > > Another question is synchronization of status changes with input. I've > > [...] > > or, having stream_read block (return EAGAIN or another error for this case) > > until you've polled for status information. > > This sounds more easier to implement. If it is no problem I would > rather do this one :) > Some events are synchronous with the data stream : parity error, framing error, overrun, break. Some API's report these events by using 16bit per received byte where the lowest 8bits are the received data, and bit 8 - 12 indicate parity error, framing error, overrun and break. Perhaps we should add 2 extra methods : read_extended which gives you the 16bits format + timestamp, write_extended which takes 8bits + parity + break and a timestamp. This would allow you to do properly timed breaks, use the parity bit as a data bit on uarts that allow you to, and perhaps abuse a uart to do remote control infrared or other hardware hacks :) Doesn't really look like a normal serial API though :) but hey, it's cool ! (and you can still run PPP on it :)) Cheers, p2. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
