Nuttx for Calypso

[Harald Welte]

Hi Stefan,

On Wed, May 25, 2011 at 12:13:31AM +0200, l--putt wrote:

> Before I spend more work on the current code: Is the sercomm protocol
> successful and will stay? 

yes.

> What interface to userspace do you suggest?

each DLC should be a separate device e.g. /dev/ttyHDLC0.., so a
userspace process can simply open one DLC and read/write to it using
stadard read/write calls.

> Should be something that works on Linux if our stuff ends up on more
> powerful devices. My proposal: A char device /dev/sercomm Each time you
> open it, it starts a new channel. 

No, please make it explicit and have one device for each DLC
Automatically assigning a channel is not a useful feature.

> With ioctl, you can change the channel. 

then you would have to do that ioctl() every time.   I like the idea of
one device per DLC better.

> Each write is send as a message. Nuttx has buffers for stdio and hence
> will take care that there are not too many messages (I hope :P
> ) 

> The receive part: a blocking read?

either blocking read, or the user can set O_NONBLOCK and do select/poll
(not sure if nuttx supports that, but at least on Linux it would work)

In terms of Linux there may already be a more generic serial multiplexer
protocol that we can re-use.  Not sure if it finally has a TS07.10
multiplexer, e.g.  If yes, the we may consider switching to TS07.10
instead of our homebrew HDLC.

In any case, on Linux the multiplex driver would be bound as a line
discipline to the real serial port, and offers N virtual serial ports
for the N DLCs.

> > Do you see any problems with this?  Is there something in the Nuttx
> > ARM7TDMI related code that disables FIQs or otherwise interferes with
> > them?
> 
> I thought local_fiq_disable() in secomm_cons messes around with FIQs.
> Why is that save or what does it actually do?

it is neccessary as we also want to log messages from the L1.  Right now
the L1 (from FIQ) submits a log message, and the normal code in the UART
driver fetches those messages and writes them to the UART.  You need
some kind of locking/mutex for a very short time to protect the queue of
messages here.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)