On 8 February 2011 02:25, Denis Kenzior <[email protected]> wrote:
>>> Actually we should for files that are read during pre-sim but are not
>>> important enough. E.g. EFecc, EFli, EFpl, EFiccid, etc.
>>
>> But if we "restart SIM initialization procedure", we already re-read
>> those files so there's nothing more we need to do. The sim
>> initialization in 51.011 includes reading those files if I remember
>> correctly.
>>
>
> I'm still fuzzy on this one. EFpl/EFli and EFiccid are in a different
> DF than the rest of the files, so they might not need to be initialized
> again in practice, unless we're performing a full reset.
Maybe, although it's such a rare situation that I don't think we're
gaining anything here by making an assumption that is not documented
in any spec.
I'm also fuzzy on what the differences between the Refresh types are
for us but we can't go wrong by re-reading all files.
>
> In the case of EFecc, the file is on voicecall atom, so the change watch
> has to be fired anyway. So using my approach it works out nicely.
>
>>>
>>>>
>>>>> else
>>>>> for each file changed:
>>>>> notify matching remaining watches
>>>>
>>>> What if a file is changed which doesn't have a handler implemented?
>>>> Shouldn't we fall back to removing the atom? That was the idea of
>>>> those "complicated" loops above.
>>>
>>> If it should be handled, then its a bug. Removing all atoms just
>>> because someone forgot to handle a file is bad anyway.
>>
>> We don't need to remove atoms, in this patch series we simply signal
>> "sim ready" to atoms in those cases. Otherwise all those NULL watches
>> are useless, right? The reason I introduced the NULL-callback watches
>> is because there are many files, like EFcfis, which are unlikely to be
>> changed by the SIM application or operator. Yet we can't ignore them,
>> in case we receive a Refresh on those files. We have two dozens of
>> such files and it's not practical to add notifiers for all of them,
>> it's easier to fall back to re-reading all of the post-sim files.
>
> Honestly I think we should handle all of them, one by one. It might
> take a little while, but we have to anyway in the long run. We can
> concentrate on the important ones first, e.g. EFcsp, EFspn, EFopl,
> EFecc, etc. Sure, in the short term we might not handle each and every
> file that could be sent via Refresh. But then we just acknowledge it as
> a bug and fix it later. Re-initializing everything just because e.g.
> EFmbdn or some other unimportant file changed and we're too lazy to fix
> it is just not a good idea anyway.
So maybe we should return "Not capable" to a refresh that touches any
of those files? At the very least we would need to log some kind of
warning. (Then again these user-writable files are so unlikely to be
changed that I don't think we're losing anything by being safe and
re-reading everything)
>
>>
>> In the patch 3/4 I've added watches for all of the files where changes
>> need to be somehow handled. Most of them have NULL callback because
>> they're not really important and it would be a huge patch if wanted to
>> have a handler for every single file, although we can add them
>> gradually later. The files where changes don't need to be handled,
>> don't register a watch at all (like EFcbmi, EFcbmir which are only
>> used for initialising our own topics list)
>
> I know what you're trying to accomplish, but I don't think we need this
> flexibility. The 'important' files that are likely to change have to be
> handled anyway. For the 2G/3G/CPHS cases we cover most of the EFs that
> are required, so we have a good handle on what is needed. We might be
> missing one or two, but certainly not dozens. So let us keep things simple.
>
>>
>>>
>>>>
>>>>>
>>>>> Incidentally the above list of files to re-read is exactly the same
>>>>> files we need to re-initialize when we lock ourselves out when trying to
>>>>> lock/unlock/change the PIN.
>>>>>
>>>>>> + switch (reset_state) {
>>>>>> + case RESET_REMOVE_ATOMS:
>>>>>> + /*
>>>>>> + * REVISIT: There's some concern that on re-insertion the
>>>>>> + * atoms will start to talk to the SIM before it becomes
>>>>>> + * ready, on certain SIMs.
>>>>>> + */
>>>>>> + ofono_sim_inserted_notify(sim, FALSE);
>>>>>> + ofono_sim_inserted_notify(sim, TRUE);
>>>>>> + break;
>>>>>
>>>>> This is not really a good idea semantics wise. The SIM hasn't really
>>>>> been removed and a UICC reset / NAA application reset / NAA session
>>>>> reset is not being performed either.
>>>>
>>>> Hmm probably. Although from our point of view the NAA initialisation
>>>> looks the same as sim re-insertion so we end up inlining that fuction.
>>>>
>>>
>>> I'm still fuzzy on what NAA initialization actually does. Right now my
>>> interpretation is that EFpl/EFli and EFiccid have not changed. So it is
>>> not quite the same as a reset.
>>
>> However with Full file change notification they may have changed, so
>> it's a safe fallback to re-read them.
>
> Your guess is as good as mine right now, however we need this
> functionality anyway for the 'SIM PIN locked out after we're in
> sim_ready state' case anyway. Or if lets say we get a File Changed
> Notification with EFfdn for example. There's no sense in re-reading
> EFiccid, EFpl/EFli as well.
In case of EFfdn I think we should eventually have a handler which
will do the right thing and remove or create the affected atoms as
necessary.
But I don't see why EFpl shouldn't change during a Refresh with Full
file change notification. I wouldn't call it a guess as much as being
ready for anything :) It's not like this is not allowed to happen, so
there's no reason to think it can't happen.
Any of those files can also be explicitly speciied in the changed
files list. Maybe the solution is to just use a different reset_level
value when calling sim_add_file_watch for such files.
Best regards
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
