28 Apr
2015
28 Apr
'15
3:39 p.m.
Hi,
On Friday, April 24, 2015 4:41:53 PM, Nico Golde wrote:
All right, thanks for clarifying. I went ahead and did the change: now sim.c calls either
l1ctl or sap_interface and they both call back to sim.c when they have a result. The
function that gets called in sap_interface.c has now the same signature as the one in
l1ctl suggesting they provide an interface for the same task (which they do indeed).
I attached the revised patch.
Some background info/documentation:
By default the mobile app will try to use the SAP backend instead of the built in SIM
reader. If it fails to connect to the default SAP socket (/tmp/osmocom_sap) it'll
fallback to the phone's built-in SIM slot.
To use the SAP backend you'll need softSIM which will create the socket and also
interact with a PC/SC reader or a previously captured file (sim_os). First you need to
start up the demo_server with the right parameters based on your setup (-s unix to create
the socket for the mobile app, -t type depends on whether you have a PC/SC reader or not).
After that osmocon could be started, then the mobile app, then the phone itself.
When starting up the mobile app one can observe the debug information from the SAP
interface by default.
Regards,
Domi
One thing
however that I think is strange, and worth mentioning: I'm not
sure why Nico decided to implement the switch between phone and SAP-client
inside of l1ctl.c, for me it would feel better to do it in sim.c (since
sim.c deals with SIM activities, l1ctl should deal only with L1 stuff...also
the current SAP client calls back to sim.c, but receives data from l1ctl -
little bit confusing), but I left it as is because of not knowing exactly
the thoughts behind it.
I don't remember details to be honest as this is too long ago, but I think
there was no real design decision behind this other than that the code that is
sending traffic to the SIM was already in l1ctl and I just added the switch...