Hi Oleg,
On 04/25/2012 05:59 AM, Oleg Zhurakivskyy wrote:
> Hello Denis,
>
> On 04/24/2012 12:28 AM, Denis Kenzior wrote:
>>> static void ss_set_query_cf_callback(const struct ofono_error *error,
>>> int total,
>>>
>>> set_new_cond_list(cf, cf->query_next, l);
>>>
>>> + if (cf->query_next == CALL_FORWARDING_TYPE_UNCONDITIONAL&&
>>> + cf->query_next == cf->query_end) {
>>> + cf->flags |= CALL_FORWARDING_FLAG_CACHED;
>>> + /*
>>> + * CFU has been disabled, conditionals need to be updated
>>> + */
>>> + if (is_cfu_enabled(cf) == FALSE)
>>> + cf->query_end = CALL_FORWARDING_TYPE_NOT_REACHABLE;
>>
>> So a bit of background, the original set + query logic did not mess with
>> the CACHED flag. The assumption was that we're modifying a single
>> property. If the CACHED flag was already set, then the modification was
>> queried and the CACHED flag was still valid. If the CACHED flag was not
>> set, then we'd re-query the entire thing anyway.
>>
>> Now we have a somewhat funny situation where when we clear CFU, we are
>> essentially forced into querying everything. The immediate problem with
>> your approach is that we can't return from the method call until all
>> settings have been queried. By convention the core can have only a
>> single outstanding call into the driver at a time. We bend the rules
>> somewhat, but in general we need to stick to this rule. This is why you
>> see busy error conditions everywhere. So likely this needs a specific
>> code path ...
>
> OK, thanks, I see. Would it make sense to return the method immediately
> and then to re-query the conditionals? Or, just to wait until anybody
> needs them?
This probably needs a bit of thought, but here's one possible strategy,
feel free to suggest any improvements:
- If unconditional is reset and conditionals are known (e.g. they were
queried before and not cleared) then we can simply signal them here
- If the unconditional is reset and the CACHED flag is not set (e.g. the
application didn't trigger a GetProperties yet) then we probably can
skip the re-query, the next GetProperties will do it for us.
- If unconditional is reset and CACHED is set but we don't know the
conditionals, then we should query all conditionals before returning
from the method call.
>
>> Also, there is an optimization we can make here, e.g. if we queried the
>> conditional forwarding settings prior to CFU being enabled, then we can
>> keep those around. This is why the TODO item refers to the 'conditional
>> cache.' In the case of CFU being flipped to enabled and then disabled,
>> we do not need to query.
>
> Thanks for the help here. Let's go for this approach too.
Okay, just remember the conditionals can be erased when CFU is active,
including through MMI codes.
Regards,
-Denis
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
