Re: gnumach2 & the serial port

[Unknown]

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.