Hmm we can take this the reverse way: <div>Instead of implementing PCSC for the phone SIM, we can implement the phone API for PCSC.</div><div>This will me MUCH more simpler.</div><div>A thread with a queue to collect the commands and call the callback when the response is received, then we're done (yes, pcsc is synchronous)<br>


<br><div class="gmail_quote">On Tue, Mar 9, 2010 at 4:54 PM, Harald Welte <span dir="ltr"><<a href="mailto:laforge@gnumonks.org" target="_blank">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">


<div>On Tue, Mar 09, 2010 at 04:25:11PM +0100, Sébastien Lorquet wrote:<br>
<br>
> I don't know which GSM stack layer needs to exchange APDUs. I guess it's not<br>
> level 1,<br>
<br>
</div>In normal GSM stacks, yes, the Layer1 provides an abstraction layer for<br>
SIM card access.<br>
<br>
Hwoever, the actual SIM card read/write commands come from Layer 3 or<br>
the application above that.<br>
<div><br>
> so apdus will be exchanged through the serial link with the phone.<br>
> It may be nice to have a pcsclite driver to drive the sim card in the phone.<br>
> Then we'll be able to use a SIM cards connected to the real phone, or a ccid<br>
> smart card reader connected to the PC running the layer2/layer3, using the<br>
> same API.<br>
<br>
</div>Yes, I like that idea, and we can easily use yet another of our HLDC<br>
data link connections for this.<br>
<br>
However, it seems almost like a bit of over-engineering to me to go a<br>
far as to support PC/SC.  Sure, it's a cool hack, and if somebody has<br>
an interest in it and some time to spare.<br>
<br>
But then, as long as the Layer3 is on the PC, it would be fine if it can<br>
support real PC/SC readers.  Only when we start to support running<br>
layer3 inside the phone, we would require the use of the SIM card reader<br>
inside the phone.<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div>- Harald Welte <<a href="mailto:laforge@gnumonks.org" target="_blank">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>
</div></div></blockquote></div><br></div>