We cross posted, you gave me more info, thanks.<div>The async approach seems very nice here.</div><div><br>Sebastien</div><div><br><div class="gmail_quote">On Tue, Mar 9, 2010 at 4:24 PM, Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>></span> wrote:<br>

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