Re: [gprs-provision RFCPATCHv6 0/4] Plugin API for provisioning of GPRS context settings
Hi Aki, > > lets get this merged without support for SPN for now. We can easily add > > this later. So please fix Denis' comments and re-submit this without the > > SPN change. > > > > Andrew is currently looking into fixing the SIM reading race. Once that > > is done we can tackle the SPN part. Feel free to add a TODO item for > > adding access to SPN information. > > By SIM race do you mean an atom getting removed while it has a pending > ofono_sim_read? exactly that one. See discussion on IRC. > > Right now I think we need to do that in the SIM atom, store it, and then > > provide it for netreg and other plugins that might want it. However we > > might need to discuss this a bit further. > > I think this is actually easy to fix internally to the sim atom. The > first ofono_sim_read() to EFspn would initiate an async read, and any > call to ofono_sim_read() after the fact would pend on that single read > results, or return immediately with cached results if available. I let Andrew to comment on this. He is already looking into this. > So I don't see the point in removing the SPN code from provisioning > right now. It is a necessary part of the solution, so at least we need > to keep the task open as long as SPN is not in. The SPN is not required by provisioning itself. It is required by the provisioning plugins. That is why I said we should put a new item in the TODO list to track it. Or maybe just storing SPN in the SIM atom with a proper API for plugins and netreg to access it. However I do wanna decouple this from this set of patches now. Otherwise we are turning in circles and not getting anywhere. Same as we decoupled the SIM MCC/MNC getter patches. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [gprs-provision RFCPATCHv6 0/4] Plugin API for provisioning of GPRS context settings
Hi Marcel, 2011/1/26 Marcel Holtmann : > lets get this merged without support for SPN for now. We can easily add > this later. So please fix Denis' comments and re-submit this without the > SPN change. > > Andrew is currently looking into fixing the SIM reading race. Once that > is done we can tackle the SPN part. Feel free to add a TODO item for > adding access to SPN information. By SIM race do you mean an atom getting removed while it has a pending ofono_sim_read? > Right now I think we need to do that in the SIM atom, store it, and then > provide it for netreg and other plugins that might want it. However we > might need to discuss this a bit further. I think this is actually easy to fix internally to the sim atom. The first ofono_sim_read() to EFspn would initiate an async read, and any call to ofono_sim_read() after the fact would pend on that single read results, or return immediately with cached results if available. There is still the SIM race problem, but I would really rather solve that problem by always having all atoms created and removed in the same callbacks, without returning to mainloop. Whether atoms register any D-Bus API in certain modem states is then a different matter. But the lifetime of all atoms should be the same, and then the SIM race is again a local matter to the SIM atom to fix. E.g., cancelling any pending reads it has on the SIM when it gets removed. Simply removing the driver should take care of this, in fact (at least isimodem should handle such a thing gracefully). So I don't see the point in removing the SPN code from provisioning right now. It is a necessary part of the solution, so at least we need to keep the task open as long as SPN is not in. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [gprs-provision RFCPATCHv6 0/4] Plugin API for provisioning of GPRS context settings
Hi Jukka, > > I think that our only leftover is how we handle the SPN detail. > > > > Denis, what is your preference here? My take would be that we store it > > inside network registration and provide it to external modules. I don't > > see a point in reading it twice. > > New SPN specific API in SIM atom? Asynchronous with callback, but SIM > would need to read it only once. > Unless there is some simple way to start reading it right after SIM is > ready/unlocked and netreg and gprs are registered only after SPN read > returns? lets get this merged without support for SPN for now. We can easily add this later. So please fix Denis' comments and re-submit this without the SPN change. Andrew is currently looking into fixing the SIM reading race. Once that is done we can tackle the SPN part. Feel free to add a TODO item for adding access to SPN information. Right now I think we need to do that in the SIM atom, store it, and then provide it for netreg and other plugins that might want it. However we might need to discuss this a bit further. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [gprs-provision RFCPATCHv6 0/4] Plugin API for provisioning of GPRS context settings
Hi On Tue, 2011-01-25 at 13:28 +0100, ext Marcel Holtmann wrote: > I think that our only leftover is how we handle the SPN detail. > > Denis, what is your preference here? My take would be that we store it > inside network registration and provide it to external modules. I don't > see a point in reading it twice. New SPN specific API in SIM atom? Asynchronous with callback, but SIM would need to read it only once. Unless there is some simple way to start reading it right after SIM is ready/unlocked and netreg and gprs are registered only after SPN read returns? --Jukka ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [gprs-provision RFCPATCHv6 0/4] Plugin API for provisioning of GPRS context settings
Hi Jukka, > Another patchset about automatic provisioning of GPRS context settings. > > This time, provisioning driver API is synchronous, and > __ofono_gprs_provision_get_settings includes MCC,MNC and SPN as in > parameters. > Per modem probing and all related complexity was removed, since there was > really no need for it. > > It is now the gprs-atom that queries SPN from SIM before calling > provisioning. Cases when gprs-atom is unregistered or removed while SPN query > is in progress, should be handled gracefully (unlike e.g. in netreg atom...) I think that our only leftover is how we handle the SPN detail. Denis, what is your preference here? My take would be that we store it inside network registration and provide it to external modules. I don't see a point in reading it twice. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[gprs-provision RFCPATCHv6 0/4] Plugin API for provisioning of GPRS context settings
Hello Another patchset about automatic provisioning of GPRS context settings. This time, provisioning driver API is synchronous, and __ofono_gprs_provision_get_settings includes MCC,MNC and SPN as in parameters. Per modem probing and all related complexity was removed, since there was really no need for it. It is now the gprs-atom that queries SPN from SIM before calling provisioning. Cases when gprs-atom is unregistered or removed while SPN query is in progress, should be handled gracefully (unlike e.g. in netreg atom...) --Jukka Saunamäki Jukka Saunamaki (4): gprs-provision: add driver API header gprs-provision: add driver API sources gprs: add gprs context provisioning gprs-provision: add example context provisioning driver Makefile.am |8 ++- examples/provision.c | 97 ++ include/gprs-provision.h | 69 ++ src/gprs-provision.c | 104 src/gprs.c | 172 +++--- 5 files changed, 438 insertions(+), 12 deletions(-) create mode 100644 examples/provision.c create mode 100644 include/gprs-provision.h create mode 100644 src/gprs-provision.c ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
