From: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
To: ofono@ofono.org
Subject: Re: [PATCHv2 2/3] network: Add CPHS SPN, short-SPN fallbacks
Date: Tue, 20 Dec 2011 15:19:22 +0200 [thread overview]
Message-ID: <4EF08B5A.2060005@intel.com> (raw)
In-Reply-To: <4EF02C71.7020008@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
Hello Denis,
On 12/20/2011 08:34 AM, Denis Kenzior wrote:
> You have to be careful here since you can't really guarantee that the
> operation will succeed in your time allotted. If you are unlucky the
> timer will fire before the entire transaction succeeds and you might be
> running the old transaction and the new transaction in parallel. You
> would have to check if the current code can handle this, but probably
> not. And of course you never know what timer value is large enough.
Just a little more explanation here. The g_timeout_add() is periodical, in
unlucky case it will run a few times checking whether the SPN reading flag is
cleared and only after that will trigger the new read operation and unregister
itself. Since we clear the flag in all SPN read callbacks in all cases, this
should be safe.
> A better approach might be to set another flag in this case, e.g.
> RECHECK_SPN, and re-do the transaction. However, you'd also need to
> make sure the sim file cache is flushed as well.
This might be more efficient, let me check this.
>> I will be sending SPN changes for src/gprs.c soon.
>
> Before you do this, a sanity check on whether any MVNOs actually use the
> CPHS SPN field might be in order. It may be that this complexity is not
> needed in the gprs.c provisioning logic; and that the EFspn field is
> sufficient.
Sure, that makes sense. I haven't found anything on usage of CPHS SPN by MVNOs.
However, that doesn't mean nobody is using it. Anyway, that change won't touch
the provisioning logic, might this be useful, the patch is almost ready, just
decide when you see it.
Regards,
Oleg
--
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
next prev parent reply other threads:[~2011-12-20 13:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-13 11:36 [PATCHv2 0/3] CPHS SPN, short-SPN support Oleg Zhurakivskyy
2011-12-13 11:36 ` [PATCHv2 1/3] network: Use netreg_emit_operator_display_name() Oleg Zhurakivskyy
2011-12-16 6:46 ` Denis Kenzior
2011-12-13 11:36 ` [PATCHv2 2/3] network: Add CPHS SPN, short-SPN fallbacks Oleg Zhurakivskyy
2011-12-17 0:54 ` Denis Kenzior
2011-12-19 12:58 ` Oleg Zhurakivskyy
2011-12-20 6:34 ` Denis Kenzior
2011-12-20 13:19 ` Oleg Zhurakivskyy [this message]
2011-12-20 15:32 ` Denis Kenzior
2011-12-21 8:48 ` Oleg Zhurakivskyy
2011-12-13 11:36 ` [PATCHv2 3/3] TODO: Remove completed CPHS SPN and short-SPN tasks Oleg Zhurakivskyy
2011-12-17 0:54 ` Denis Kenzior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EF08B5A.2060005@intel.com \
--to=oleg.zhurakivskyy@intel.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.