Re: [RFC 1/1] GPRS Provisioning Plugin.
Hello Denis, On 07/08/2011 09:23 PM, Denis Kenzior wrote: What I wonder is what is the overhead of the XML parser right now (e.g. how long it takes on reasonable embedded hardware). If this takes a while, then it might be better to pre-parse the mobile-provider-info db during plugin initialization and not every time gprs_provision is called. Otherwise we run the risk of hanging the daemon while the provision settings are being looked up. Thanks for the input. Yes, this might be the problem. I could try to test with N900 in order to get the idea of how long the parsing can take. Pre-parsing might be a good idea anyway, I will try to check how feasible it is. Regards, Oleg - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/1] GPRS Provisioning Plugin.
On Friday 08 July 2011 21:23:34 ext Denis Kenzior, you wrote:
Hi Oleg,
snip
+static int gprs_provision(const char *mcc, const char *mnc,
+ const char *spn,
+ struct ofono_gprs_provision_data **settings,
+ int *count)
+{
+ int i;
+ struct parser_data *data;
+ *settings = NULL;
+
+ DBG(Provisioning for MCC %s, MNC %s, SPN '%s',
+ mcc, mnc, spn);
+
+ data = g_try_new0(struct parser_data, 1);
+ if (data == NULL)
+ return -ENOMEM;
+
+ lookup_apn(mcc, mnc, NULL, data);
What I wonder is what is the overhead of the XML parser right now (e.g.
how long it takes on reasonable embedded hardware). If this takes a
while, then it might be better to pre-parse the mobile-provider-info db
during plugin initialization and not every time gprs_provision is
called. Otherwise we run the risk of hanging the daemon while the
provision settings are being looked up.
Provisioning should be a fairly rare occurence. Preparsing the table into
memory might be a waste of both CPU and memory in the common circumstances...
If you suspect the parser is slow (I doubt it, but I have not checked), then
it might be better to just do it in a separate thread in the rare cases that
you actually do need the data.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH] rules: Add ofono rules for ZTE MF190
---
plugins/ofono.rules |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/plugins/ofono.rules b/plugins/ofono.rules
index 1fcdddb..794a02d 100644
--- a/plugins/ofono.rules
+++ b/plugins/ofono.rules
@@ -24,6 +24,9 @@ ATTRS{idVendor}==19d2, ATTRS{idProduct}==0063,
ENV{OFONO_IFACE_NUM}==01, E
ATTRS{idVendor}==19d2, ATTRS{idProduct}==0117, ENV{OFONO_IFACE_NUM}==02,
ENV{OFONO_ZTE_TYPE}=modem
ATTRS{idVendor}==19d2, ATTRS{idProduct}==0117, ENV{OFONO_IFACE_NUM}==01,
ENV{OFONO_ZTE_TYPE}=aux
+ATTRS{idVendor}==19d2, ATTRS{idProduct}==0124, ENV{OFONO_IFACE_NUM}==04,
ENV{OFONO_ZTE_TYPE}=modem
+ATTRS{idVendor}==19d2, ATTRS{idProduct}==0124, ENV{OFONO_IFACE_NUM}==01,
ENV{OFONO_ZTE_TYPE}=aux
+
ATTRS{idVendor}==19d2, ATTRS{idProduct}==0017, ENV{OFONO_IFACE_NUM}==03,
ENV{OFONO_ZTE_TYPE}=modem
ATTRS{idVendor}==19d2, ATTRS{idProduct}==0017, ENV{OFONO_IFACE_NUM}==01,
ENV{OFONO_ZTE_TYPE}=aux
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/1] GPRS Provisioning Plugin.
Hello Marcel, On 07/08/2011 07:55 PM, Marcel Holtmann wrote: Now I question if we should bother with multiple settings anyway. In the end we have 1 Internet context and 1 MMS context coming from this type of database. That's a good point. So, let's stick to max 2 settings for now. If there will be need in more than 2 settings, let's come back to this then. Thanks for the comments. I will prepare and submit another patch. Regards, Oleg - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/1] GPRS Provisioning Plugin.
Hi Rémi,
On 07/11/2011 03:11 AM, Rémi Denis-Courmont wrote:
On Friday 08 July 2011 21:23:34 ext Denis Kenzior, you wrote:
Hi Oleg,
snip
+static int gprs_provision(const char *mcc, const char *mnc,
+ const char *spn,
+ struct ofono_gprs_provision_data **settings,
+ int *count)
+{
+ int i;
+ struct parser_data *data;
+ *settings = NULL;
+
+ DBG(Provisioning for MCC %s, MNC %s, SPN '%s',
+ mcc, mnc, spn);
+
+ data = g_try_new0(struct parser_data, 1);
+ if (data == NULL)
+ return -ENOMEM;
+
+ lookup_apn(mcc, mnc, NULL, data);
What I wonder is what is the overhead of the XML parser right now (e.g.
how long it takes on reasonable embedded hardware). If this takes a
while, then it might be better to pre-parse the mobile-provider-info db
during plugin initialization and not every time gprs_provision is
called. Otherwise we run the risk of hanging the daemon while the
provision settings are being looked up.
Provisioning should be a fairly rare occurence. Preparsing the table into
memory might be a waste of both CPU and memory in the common circumstances...
I do agree here, but it is the lesser evil than hanging the daemon for x
seconds. However, first I'd like to know what the parsing speed is...
If you suspect the parser is slow (I doubt it, but I have not checked), then
it might be better to just do it in a separate thread in the rare cases that
you actually do need the data.
Separate thread will not help since the function has to return
synchronously. I doubt the overhead of storing this information will be
big, but if it is then we can play other tricks like pre-parsing the db
into a quick-look-up file format at start-up, etc.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] rules: Add ofono rules for ZTE MF190
Hi Nicolas, On 07/11/2011 07:16 AM, Nicolas Bertrand wrote: --- plugins/ofono.rules |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Patch has been applied, thanks. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] rules: Add oFono rule for SpeedUp 7300 modem
---
plugins/ofono.rules |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/plugins/ofono.rules b/plugins/ofono.rules
index 794a02d..27615cc 100644
--- a/plugins/ofono.rules
+++ b/plugins/ofono.rules
@@ -365,6 +365,10 @@ ATTRS{idVendor}==1bc7, ATTRS{idProduct}==1004,
ENV{OFONO_IFACE_NUM}==03, E
ATTRS{idVendor}==1c9e, ATTRS{idProduct}==9800, ENV{OFONO_IFACE_NUM}==01,
ENV{OFONO_SPEEDUP_TYPE}=modem
ATTRS{idVendor}==1c9e, ATTRS{idProduct}==9800, ENV{OFONO_IFACE_NUM}==02,
ENV{OFONO_SPEEDUP_TYPE}=aux
+# SpeedUp 7300
+ATTRS{idVendor}==1c9e, ATTRS{idProduct}==9e00, ENV{OFONO_IFACE_NUM}==00,
ENV{OFONO_SPEEDUP_TYPE}=modem
+ATTRS{idVendor}==1c9e, ATTRS{idProduct}==9e00, ENV{OFONO_IFACE_NUM}==03,
ENV{OFONO_SPEEDUP_TYPE}=aux
+
LABEL=ofono_tty_end
# ISI/Phonet drivers
--
1.7.4.1
-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: Les Montalets- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Fix issue with AT parser in gatserver
Hi Frederic, On 07/08/2011 09:44 AM, Dalleau, Frederic wrote: Hi Denis, 2011/7/7 Denis Kenzior denk...@gmail.com: Hi Frédéric, On 07/07/2011 09:19 AM, Frédéric Dalleau wrote: This patch fix an issue with AT parser in gatserver. If an empty command is issued after AT, then 2 answers are sent. The parser can also get in a bad state where next commands will not be handled. After that the parser will get back on his feets. This is caused by reentrency: new_bytes() calls g_at_server_send_final(), which in turns calls server_resume which calls new_bytes() again synchronously. We should not try to set the read handler if it already set. Have you tried adding: if (server-suspended == FALSE) return; I like the idea of this one, but it still exhibit an issue in the case of A/: Server_parse_line suspends and resumes in the same function. I think I fixed this one as well in commit 329f2d7. Let me know if you encounter further problems. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
