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. <snip> 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 [email protected] http://lists.ofono.org/listinfo/ofono
