Hi Marcel, 2011/1/26 Marcel Holtmann <mar...@holtmann.org>: > 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
