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