This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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)