Sébastien Lorquet squalyl at
Tue Mar 9 15:27:19 UTC 2010

We cross posted, you gave me more info, thanks.
The async approach seems very nice here.


On Tue, Mar 9, 2010 at 4:24 PM, Harald Welte <laforge at> wrote:

> Hi dexter,
> thanks for your update!
> On Tue, Mar 09, 2010 at 03:12:47PM +0100, dexter wrote:
> > I have now getting interrupts and i am sending the first little
> > APDUs to the card. I think i will have something that basicly works
> > soon.
> > But up to now i think it will be impossible to save processing time
> > during the transmission - wait phases without having semaphores (or
> > something semilar that can be used to wait for an event without
> > wasting processing time in a while loop.) However - this only makes
> > sense with a multitasking os which we actually do not have ;-)
> yes, if you think about a synchronous / "blocking I/O" scenario.
> However, you could always have something asynchronous:  The caller calls
> something like sim_card_transceive(*message, *cb), and the driver calls
> back the 'cb' function when it has received the data.
> I think the latter is the best we can do at the moment.
> Another possible concept is to introduce some kind of message queue: The
> entity that wants to issue a command to the SIM sends a message into the
> queue, indicating to which other message queue any responses shall be
> queued to.
> I agree the synchronous approach seems to be the more natural one
> (for most human beings at least).  However, it comes at the cost of
> scheduling overhead/latency, new possibilities for deadlocks and
> potentially difficult debugging than in a single-threaded program.
> Right now I don't really know yet how many threads/tasks we will end up
> having.  I only know we should be careful and not to have too many of
> them.  Layer2 is certainly going to be one task, Layer3 will have at
> least one.  Layer3 is he entity that normally talks to the SIM, at least
> excluding things coming directly from the app like phonebook access and
> storing SMS.
> > The driver will get a function like sim_card_transceive(*message,
> > *response) or so on because a transaction with the card will never
> > be receive or send only. You always send something to the card and
> > you always get something back.
> If the caller does not care, he could simply specify a NULL pointer as
> *response.
> --
> - Harald Welte <laforge at>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the baseband-devel mailing list