Hi Marcel, >if we talk about the SAP server role found in a mobile phone, >then that support clearly needs to interact with the telephony >stack. Since when SAP is active the telephony stack needs to >be suspended and all SIM transaction being forwarded. I agree, but a telephony stack needs to care about its state when SAP is active. Not all linux based mobile platforms use ofono. >Currently I would be thinking that the SAP implementation >should be done inside oFono actually. Since then you have >direct access to the hardware. The D-Bus approach just doesn't >sound correct to me. I could be of course wrong, but I can't >wrap my mind around on how you can make this work. I assume that ofono should handle sap transactions (as it's kind of hardware abstraction for bluez) and expose SAP APDU interfaces as i.e Nokia did for sap transactions in spec (http://www.wirelessmodemapi.com/), and not implement sap profile itself. Again, not all use ofono as telephony stack. Sorry, I don't know ofono well. What's the interface between ofono and bluez? >Even with file descriptor passing this doesn't look like the >right approach. If we need a hardware abstraction than we >either use oFono or we have to create some SAP hardware access >abstraction. I agree with this too. I prefere to have a sap implementation as bluez plugin, but we need to define api for sim operations which could be implemented in ofono or other proprietary stacks. I guess dbus was intended to be kind of hw abstraction api. Some time ago Claudio sent proposal implementation of sap server where he defined api for a driver to sim. Regards, /Waldek-- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
