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/.
Sébastien Lorquet squalyl at gmail.comHmm we can take this the reverse way: Instead of implementing PCSC for the phone SIM, we can implement the phone API for PCSC. This will me MUCH more simpler. 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) On Tue, Mar 9, 2010 at 4:54 PM, Harald Welte <laforge at gnumonks.org> wrote: > On Tue, Mar 09, 2010 at 04:25:11PM +0100, Sébastien Lorquet wrote: > > > I don't know which GSM stack layer needs to exchange APDUs. I guess it's > not > > level 1, > > In normal GSM stacks, yes, the Layer1 provides an abstraction layer for > SIM card access. > > Hwoever, the actual SIM card read/write commands come from Layer 3 or > the application above that. > > > so apdus will be exchanged through the serial link with the phone. > > It may be nice to have a pcsclite driver to drive the sim card in the > phone. > > Then we'll be able to use a SIM cards connected to the real phone, or a > ccid > > smart card reader connected to the PC running the layer2/layer3, using > the > > same API. > > Yes, I like that idea, and we can easily use yet another of our HLDC > data link connections for this. > > However, it seems almost like a bit of over-engineering to me to go a > far as to support PC/SC. Sure, it's a cool hack, and if somebody has > an interest in it and some time to spare. > > But then, as long as the Layer3 is on the PC, it would be fine if it can > support real PC/SC readers. Only when we start to support running > layer3 inside the phone, we would require the use of the SIM card reader > inside the phone. > > -- > - 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) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100309/4f55645c/attachment.htm>