Discussion:
[help] Implementation of 2 internet contexts
(too old to reply)
Mylene JOSSERAND
2015-05-07 12:28:22 UTC
Permalink
Hi everyone,


I posted in December on the ofono mail list : https://lists.ofono.org/pipermail/ofono/2014-December/015531.html
I wanted to connect 2 APNs at the same time with 2 interfaces (PPP and QMI).

On Ofono side, it worked well but I had a problem to get 2 IP addresses with connman. I did not have time so I found a work-around (via udhcpc) but, now, I have time to work on it.
Currently, in connman, there is only one Internet context activation by modem : http://git.kernel.org/cgit/network/connman/connman.git/tree/plugins/ofono.c#n1137
In my case, I have one modem but I want to use two internet contexts.

I implemented some modifications to try to get it work (use of a context hashtable in the modem_data, for example) but I am stuck with the function "context_set_active" called in "network_connect" (http://git.kernel.org/cgit/network/connman/connman.git/tree/plugins/ofono.c#n2531).

The "network_connect" function activates the context but, with my modification, as I have two contexts, how could I know which context the user wants to activate ? I did not look how ofono and connman exchange data. Should I look at it ? Maybe, I should implement a new connman_network_driver function ?

And, in general, how would be the best way to implement a list of context ?
Why connman, currently, handles only one internet context ? I think there was a reason to implement it like this. What is it ?


Any help/advice would be appreciated.


PS : Previous test was done on connman v1.23. Now I am working on last connman 1.29.


Thank you in advance,

Best regards,
Mylène
Tomasz Bursztyka
2015-05-07 12:47:34 UTC
Permalink
Hi Mylene,

I haven't worked on this plugin but it looks like the issue a network is
added
per-modem only, not really per-modem-context.
Post by Mylene JOSSERAND
And, in general, how would be the best way to implement a list of context ?
Why connman, currently, handles only one internet context ? I think there was a reason to implement it like this. What is it ?
Yep you saw the comment on add_cm_context().

That would need to be fixed yes.
My best bet would be to revert the logic when it comes to context and
network:

instead of modem->context = ...
you could have: context->modem = modem
and modem->contexts would be a list of those context (a simple GSList).

Then you would create the network with the context as data.
For the network, try to get a name made of the modem's name, and
something that identifies the context (is there such thing? I don't know)

This require to change the structures and logic accordingly, could be
quite some work.

Tomasz
Mylene JOSSERAND
2015-05-11 12:05:35 UTC
Permalink
Hi Tomasz,


Thank you for your help.
Post by Tomasz Bursztyka
Hi Mylene,
I haven't worked on this plugin but it looks like the issue a network is added
per-modem only, not really per-modem-context.
yes, it is. I looked deeper and in the plugin, the network is created with the context path as identifier :
http://git.kernel.org/cgit/network/connman/connman.git/tree/plugins/ofono.c#n1041
With the log :
connmand[770]: src/network.c:connman_network_create() identifier /mymodem_0/context1 type 10
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
And, in general, how would be the best way to implement a list of context ?
Why connman, currently, handles only one internet context ? I think there was a reason to implement it like this. What is it ?
Yep you saw the comment on add_cm_context().
That would need to be fixed yes.
instead of modem->context = ...
you could have: context->modem = modem
and modem->contexts would be a list of those context (a simple GSList).
Yes, this is what I have done so far. I did not create a GSList but a HashTable to have the context_path, but it is pretty the same logic.
Post by Tomasz Bursztyka
Then you would create the network with the context as data.
For the network, try to get a name made of the modem's name, and something that identifies the context (is there such thing? I don't know)
In fact, the network is created with the context path as identifier. So I have the information but since it is the identifier, should I create a list of networks ? do you think it could work ? If I implement a list of network, the "add_network" and "connman_network_create" would be called twice (for the two contexts). I think you have more distance than me about the code : do you think it could work like this ?
Post by Tomasz Bursztyka
This require to change the structures and logic accordingly, could be quite some work.
Thanks for your advice

Mylène
Tomasz Bursztyka
2015-05-11 12:36:07 UTC
Permalink
Hi Mylene,
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
That would need to be fixed yes.
instead of modem->context = ...
you could have: context->modem = modem
and modem->contexts would be a list of those context (a simple GSList).
Yes, this is what I have done so far. I did not create a GSList but a HashTable to have the context_path, but it is pretty the same logic.
Unless you get dozens of contexts, go for a GSList. GHashTable does not
have tiny memory footprint.
(well, the current code is not perfect either. With an hashtable storing
context path/data pairs is also overkill.
I guess we would need to cleanup this also one day)
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
Then you would create the network with the context as data.
For the network, try to get a name made of the modem's name, and something that identifies the context (is there such thing? I don't know)
In fact, the network is created with the context path as identifier. So I have the information but since it is the identifier, should I create a list of networks ? do you think it could work ? If I implement a list of network, the "add_network" and "connman_network_create" would be called twice (for the two contexts). I think you have more distance than me about the code : do you think it could work like this ?
Actually I missed this last time. But you seem to be on the right track.
Since you are moving towards a network per context, remove the network
pointer and put it network_context structure.
You will thus get in a modem: a list of context as you did, each context
will point to its proper network structure.
So indeed you will call add_network and connman_network_create as many
times as context your modem provides.

You will have to change many functions which works on modem basis
instead of context.
(like set_connected, or netreg_update_strength where you would need to
loop on each context from the modem, etc...)
Basically, whatever exists around modem->network, you will have to adapt
the code to the new logic.

I have never touched that plugin myself, so I might miss some stuff there.


Tomasz
Frederik Lotter
2015-05-11 12:57:46 UTC
Permalink
Hi Mylene,

I only see this thread now, and I see you have already started implementing
a solution.

I had to solve the same problem.

What I have done in the end is not to change Connman, but used the fact
that a modem "disable / enable" sequence in connman translated to a context
query in ofono. In Ofono I disabled context saving and implemented a DBUS
modem context provider plugin. The way my application manages this is to
trigger a disable/enable sequence in Connman, while it also implements the
DBUS context provider, which my application manages. The application can
set the next context and then trigger the update in connman. This works
well for my application where I have to dynamically change GSM APN settings
as the hardware moves between networks.

If this could be useful to you I will be happy to share my code.

Kind Regards,
Frederik
Post by Tomasz Bursztyka
Hi Mylene,
That would need to be fixed yes.
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
instead of modem->context = ...
you could have: context->modem = modem
and modem->contexts would be a list of those context (a simple GSList).
Yes, this is what I have done so far. I did not create a GSList but a
HashTable to have the context_path, but it is pretty the same logic.
Unless you get dozens of contexts, go for a GSList. GHashTable does not
have tiny memory footprint.
(well, the current code is not perfect either. With an hashtable storing
context path/data pairs is also overkill.
I guess we would need to cleanup this also one day)
Then you would create the network with the context as data.
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
For the network, try to get a name made of the modem's name, and
something that identifies the context (is there such thing? I don't know)
In fact, the network is created with the context path as identifier. So I
have the information but since it is the identifier, should I create a list
of networks ? do you think it could work ? If I implement a list of
network, the "add_network" and "connman_network_create" would be called
twice (for the two contexts). I think you have more distance than me about
the code : do you think it could work like this ?
Actually I missed this last time. But you seem to be on the right track.
Since you are moving towards a network per context, remove the network
pointer and put it network_context structure.
You will thus get in a modem: a list of context as you did, each context
will point to its proper network structure.
So indeed you will call add_network and connman_network_create as many
times as context your modem provides.
You will have to change many functions which works on modem basis instead
of context.
(like set_connected, or netreg_update_strength where you would need to
loop on each context from the modem, etc...)
Basically, whatever exists around modem->network, you will have to adapt
the code to the new logic.
I have never touched that plugin myself, so I might miss some stuff there.
Tomasz
_______________________________________________
connman mailing list
https://lists.connman.net/mailman/listinfo/connman
Mylene JOSSERAND
2015-05-11 13:37:00 UTC
Permalink
Hi Frederik,
Post by Tomasz Bursztyka
Hi Mylene,
I only see this thread now, and I see you have already started implementing
a solution.
I had to solve the same problem.
What I have done in the end is not to change Connman, but used the fact
that a modem "disable / enable" sequence in connman translated to a context
query in ofono. In Ofono I disabled context saving and implemented a DBUS
modem context provider plugin. The way my application manages this is to
trigger a disable/enable sequence in Connman, while it also implements the
DBUS context provider, which my application manages. The application can
set the next context and then trigger the update in connman. This works
well for my application where I have to dynamically change GSM APN settings
as the hardware moves between networks.
I think I see what you are talking about.With this solution, could I have 2 APNs connected (in data mode) at the same time with different IP addresses ? Or, when the modem will be disabled in connman, it will loose his IP address ?
Post by Tomasz Bursztyka
If this could be useful to you I will be happy to share my code.
Thank you, it would be great !
It could help me a lot to see what you have done so far and try to adapt it to my problem.

Best regards,

Mylène
Post by Tomasz Bursztyka
Kind Regards,
Frederik
Post by Tomasz Bursztyka
Hi Mylene,
That would need to be fixed yes.
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
instead of modem->context = ...
you could have: context->modem = modem
and modem->contexts would be a list of those context (a simple GSList).
Yes, this is what I have done so far. I did not create a GSList but a
HashTable to have the context_path, but it is pretty the same logic.
Unless you get dozens of contexts, go for a GSList. GHashTable does not
have tiny memory footprint.
(well, the current code is not perfect either. With an hashtable storing
context path/data pairs is also overkill.
I guess we would need to cleanup this also one day)
Then you would create the network with the context as data.
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
For the network, try to get a name made of the modem's name, and
something that identifies the context (is there such thing? I don't know)
In fact, the network is created with the context path as identifier. So I
have the information but since it is the identifier, should I create a list
of networks ? do you think it could work ? If I implement a list of
network, the "add_network" and "connman_network_create" would be called
twice (for the two contexts). I think you have more distance than me about
the code : do you think it could work like this ?
Actually I missed this last time. But you seem to be on the right track.
Since you are moving towards a network per context, remove the network
pointer and put it network_context structure.
You will thus get in a modem: a list of context as you did, each context
will point to its proper network structure.
So indeed you will call add_network and connman_network_create as many
times as context your modem provides.
You will have to change many functions which works on modem basis instead
of context.
(like set_connected, or netreg_update_strength where you would need to
loop on each context from the modem, etc...)
Basically, whatever exists around modem->network, you will have to adapt
the code to the new logic.
I have never touched that plugin myself, so I might miss some stuff there.
Tomasz
_______________________________________________
connman mailing list
https://lists.connman.net/mailman/listinfo/connman
_______________________________________________
connman mailing list
https://lists.connman.net/mailman/listinfo/connman
--
Mylène JOSSERAND
Développeuse Linux Embarqué
OPEN WIDE Ingénierie - Toulouse
36, rue Jacques Babinet 31100 TOULOUSE
http://ingenierie.openwide.fr
http://www.linuxembedded.fr
Frederik Lotter
2015-05-11 14:37:45 UTC
Permalink
Hi,
Post by Mylene JOSSERAND
Hi Frederik,
Post by Tomasz Bursztyka
Hi Mylene,
I only see this thread now, and I see you have already started
implementing
Post by Tomasz Bursztyka
a solution.
I had to solve the same problem.
What I have done in the end is not to change Connman, but used the fact
that a modem "disable / enable" sequence in connman translated to a
context
Post by Tomasz Bursztyka
query in ofono. In Ofono I disabled context saving and implemented a DBUS
modem context provider plugin. The way my application manages this is to
trigger a disable/enable sequence in Connman, while it also implements
the
Post by Tomasz Bursztyka
DBUS context provider, which my application manages. The application can
set the next context and then trigger the update in connman. This works
well for my application where I have to dynamically change GSM APN
settings
Post by Tomasz Bursztyka
as the hardware moves between networks.
I think I see what you are talking about.With this solution, could I have
2 APNs connected (in data mode) at the same time with different IP
addresses ? Or, when the modem will be disabled in connman, it will loose
his IP address ?
Yes sorry, in my case connman/ofono terminates the current PPP session and
then creates a new one with a new dhcp assigned IP.
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
If this could be useful to you I will be happy to share my code.
Thank you, it would be great !
It could help me a lot to see what you have done so far and try to adapt it to my problem.
Let me know if this would still be useful for you.
Post by Mylene JOSSERAND
Best regards,
Mylène
Post by Tomasz Bursztyka
Kind Regards,
Frederik
On 11 May 2015 at 14:36, Tomasz Bursztyka <
Post by Tomasz Bursztyka
Hi Mylene,
That would need to be fixed yes.
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
instead of modem->context = ...
you could have: context->modem = modem
and modem->contexts would be a list of those context (a simple
GSList).
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
Yes, this is what I have done so far. I did not create a GSList but a
HashTable to have the context_path, but it is pretty the same logic.
Unless you get dozens of contexts, go for a GSList. GHashTable does not
have tiny memory footprint.
(well, the current code is not perfect either. With an hashtable storing
context path/data pairs is also overkill.
I guess we would need to cleanup this also one day)
Then you would create the network with the context as data.
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
For the network, try to get a name made of the modem's name, and
something that identifies the context (is there such thing? I don't
know)
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
In fact, the network is created with the context path as identifier.
So I
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
have the information but since it is the identifier, should I create a
list
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
of networks ? do you think it could work ? If I implement a list of
network, the "add_network" and "connman_network_create" would be called
twice (for the two contexts). I think you have more distance than me
about
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
the code : do you think it could work like this ?
Actually I missed this last time. But you seem to be on the right track.
Since you are moving towards a network per context, remove the network
pointer and put it network_context structure.
You will thus get in a modem: a list of context as you did, each context
will point to its proper network structure.
So indeed you will call add_network and connman_network_create as many
times as context your modem provides.
You will have to change many functions which works on modem basis
instead
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
of context.
(like set_connected, or netreg_update_strength where you would need to
loop on each context from the modem, etc...)
Basically, whatever exists around modem->network, you will have to adapt
the code to the new logic.
I have never touched that plugin myself, so I might miss some stuff
there.
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Tomasz
_______________________________________________
connman mailing list
https://lists.connman.net/mailman/listinfo/connman
_______________________________________________
connman mailing list
https://lists.connman.net/mailman/listinfo/connman
--
Mylène JOSSERAND
Développeuse Linux Embarqué
OPEN WIDE Ingénierie - Toulouse
36, rue Jacques Babinet 31100 TOULOUSE
http://ingenierie.openwide.fr
http://www.linuxembedded.fr
_______________________________________________
connman mailing list
https://lists.connman.net/mailman/listinfo/connman
Mylene JOSSERAND
2015-05-18 08:14:17 UTC
Permalink
Hi,
Post by Frederik Lotter
Hi,
Post by Mylene JOSSERAND
Hi Frederik,
Post by Tomasz Bursztyka
Hi Mylene,
I only see this thread now, and I see you have already started
implementing
Post by Tomasz Bursztyka
a solution.
I had to solve the same problem.
What I have done in the end is not to change Connman, but used the fact
that a modem "disable / enable" sequence in connman translated to a
context
Post by Tomasz Bursztyka
query in ofono. In Ofono I disabled context saving and implemented a DBUS
modem context provider plugin. The way my application manages this is to
trigger a disable/enable sequence in Connman, while it also implements
the
Post by Tomasz Bursztyka
DBUS context provider, which my application manages. The application can
set the next context and then trigger the update in connman. This works
well for my application where I have to dynamically change GSM APN
settings
Post by Tomasz Bursztyka
as the hardware moves between networks.
I think I see what you are talking about.With this solution, could I have
2 APNs connected (in data mode) at the same time with different IP
addresses ? Or, when the modem will be disabled in connman, it will loose
his IP address ?
Yes sorry, in my case connman/ofono terminates the current PPP session and
then creates a new one with a new dhcp assigned IP.
ok, this is what I though.
Post by Frederik Lotter
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
If this could be useful to you I will be happy to share my code.
Thank you, it would be great !
It could help me a lot to see what you have done so far and try to adapt
it to my problem.
Let me know if this would still be useful for you.
I do not think it will help me. Anyway, thanks for your proposition.
Post by Frederik Lotter
Post by Mylene JOSSERAND
Best regards,
Mylène
Post by Tomasz Bursztyka
Kind Regards,
Frederik
On 11 May 2015 at 14:36, Tomasz Bursztyka <
Post by Tomasz Bursztyka
Hi Mylene,
That would need to be fixed yes.
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
instead of modem->context = ...
you could have: context->modem = modem
and modem->contexts would be a list of those context (a simple
GSList).
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
Yes, this is what I have done so far. I did not create a GSList but a
HashTable to have the context_path, but it is pretty the same logic.
Unless you get dozens of contexts, go for a GSList. GHashTable does not
have tiny memory footprint.
(well, the current code is not perfect either. With an hashtable storing
context path/data pairs is also overkill.
I guess we would need to cleanup this also one day)
Then you would create the network with the context as data.
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
For the network, try to get a name made of the modem's name, and
something that identifies the context (is there such thing? I don't
know)
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
In fact, the network is created with the context path as identifier.
So I
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
have the information but since it is the identifier, should I create a
list
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
of networks ? do you think it could work ? If I implement a list of
network, the "add_network" and "connman_network_create" would be called
twice (for the two contexts). I think you have more distance than me
about
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
the code : do you think it could work like this ?
Actually I missed this last time. But you seem to be on the right track.
Since you are moving towards a network per context, remove the network
pointer and put it network_context structure.
You will thus get in a modem: a list of context as you did, each context
will point to its proper network structure.
So indeed you will call add_network and connman_network_create as many
times as context your modem provides.
You will have to change many functions which works on modem basis
instead
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
of context.
(like set_connected, or netreg_update_strength where you would need to
loop on each context from the modem, etc...)
Basically, whatever exists around modem->network, you will have to adapt
the code to the new logic.
I have never touched that plugin myself, so I might miss some stuff
there.
Post by Tomasz Bursztyka
Post by Tomasz Bursztyka
Tomasz
_______________________________________________
connman mailing list
https://lists.connman.net/mailman/listinfo/connman
Mylene JOSSERAND
2015-05-11 13:37:54 UTC
Permalink
Thomasz,
Post by Tomasz Bursztyka
Hi Mylene,
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
That would need to be fixed yes.
instead of modem->context = ...
you could have: context->modem = modem
and modem->contexts would be a list of those context (a simple GSList).
Yes, this is what I have done so far. I did not create a GSList but a HashTable to have the context_path, but it is pretty the same logic.
Unless you get dozens of contexts, go for a GSList. GHashTable does not have tiny memory footprint.
(well, the current code is not perfect either. With an hashtable storing context path/data pairs is also overkill.
I guess we would need to cleanup this also one day)
Yes, I will have only 2 contexts so, you are right, I will modify it to use a GSList.
Post by Tomasz Bursztyka
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
Then you would create the network with the context as data.
For the network, try to get a name made of the modem's name, and something that identifies the context (is there such thing? I don't know)
In fact, the network is created with the context path as identifier. So I have the information but since it is the identifier, should I create a list of networks ? do you think it could work ? If I implement a list of network, the "add_network" and "connman_network_create" would be called twice (for the two contexts). I think you have more distance than me about the code : do you think it could work like this ?
Actually I missed this last time. But you seem to be on the right track.
Good to know !
Post by Tomasz Bursztyka
Since you are moving towards a network per context, remove the network pointer and put it network_context structure.
You will thus get in a modem: a list of context as you did, each context will point to its proper network structure.
So indeed you will call add_network and connman_network_create as many times as context your modem provides.
Ok, sounds better than a network list.
Post by Tomasz Bursztyka
You will have to change many functions which works on modem basis instead of context.
(like set_connected, or netreg_update_strength where you would need to loop on each context from the modem, etc...)
Basically, whatever exists around modem->network, you will have to adapt the code to the new logic.
I have never touched that plugin myself, so I might miss some stuff there.
I understand and see (in outline) how adapt the code.
Thank you for the tips, it will help me a lot if the Frederik solution's did not work for me.

Best regards,

Mylene
Tomasz Bursztyka
2015-05-13 11:10:46 UTC
Permalink
Hi Mylene,
Post by Mylene JOSSERAND
I understand and see (in outline) how adapt the code.
Thank you for the tips, it will help me a lot if the Frederik solution's did not work for me.
Looks like Frederik's solution works with either context A or context B,
not both at same time.

Anyway, if you get a patch that works, you will be welcomed to send it
on this ML.

Tomasz
Mylene JOSSERAND
2015-05-18 12:10:02 UTC
Permalink
Hi Tomasz,
Post by Tomasz Bursztyka
Hi Mylene,
Post by Mylene JOSSERAND
I understand and see (in outline) how adapt the code.
Thank you for the tips, it will help me a lot if the Frederik solution's did not work for me.
Looks like Frederik's solution works with either context A or context B, not both at same time.
Anyway, if you get a patch that works, you will be welcomed to send it on this ML.
Okay, I will let you know if I managed to get it work.

Best regards,

Mylène
Mylene Josserand
2015-09-30 15:13:38 UTC
Permalink
Hi everyone,
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
Hi Mylene,
Post by Mylene JOSSERAND
I understand and see (in outline) how adapt the code.
Thank you for the tips, it will help me a lot if the Frederik solution's did not
work for me.
Looks like Frederik's solution works with either context A or context B, not
both at same time.
Anyway, if you get a patch that works, you will be welcomed to send it on this ML.
Okay, I will let you know if I managed to get it work.
Sorry for my (very) late answer.

I have managed to handle two (or more) internet contexts at the same time, 2-3 days after my last post but I was busy so I did not have time to send a patch.

I have implemented it (and tested it) with version 1.29. I am currently merging it to the last version of connman.

There are many modifications and I do not really know how I should categorize them into patches series. As I removed the "network" property in modem_data and added it into context_data, there are many functions that are impacted. If it is okay for you, I thought I could send one patch with all modifications and if there is a way to categorize, you could report it to me.
I tried to follow the coding style and I checked the code with checkpatch.pl script from Linux kernel. I hope it will be okay.

I will send the patch in next few days. It will be the first version so do not hesitate for any comments. I would send a version 2 with pleasure.


Best regards,

Mylène
Patrik Flykt
2015-10-01 07:16:06 UTC
Permalink
Hi,
Post by Mylene JOSSERAND
Hi everyone,
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
Hi Mylene,
Post by Mylene JOSSERAND
I understand and see (in outline) how adapt the code.
Thank you for the tips, it will help me a lot if the Frederik solution's did not
work for me.
Looks like Frederik's solution works with either context A or context B, not
both at same time.
Anyway, if you get a patch that works, you will be welcomed to send it on this ML.
Okay, I will let you know if I managed to get it work.
Sorry for my (very) late answer.
We're fine with a bit longer real world schedules, no worries here.
Post by Mylene JOSSERAND
I have managed to handle two (or more) internet contexts at the same
time, 2-3 days after my last post but I was busy so I did not have
time to send a patch.
I have implemented it (and tested it) with version 1.29. I am
currently merging it to the last version of connman.
There are many modifications and I do not really know how I should
categorize them into patches series. As I removed the "network"
property in modem_data and added it into context_data, there are many
functions that are impacted.
Ideally it should be be possible to present this kind of major
structural change with moving data from one structure to another by
creating a bigger patch that does only that with no loss of
functionality. Out of necessity this patch then touches quite many
places at the same time. Ideally the next (or previous) patch(es) in the
series would then add the desired feature change(s). But as you propose
below,...
Post by Mylene JOSSERAND
If it is okay for you, I thought I could send one patch with all
modifications and if there is a way to categorize, you could report it
to me.
...you can also send one big patch where we can help you categorizing
and splitting up the functionality into smaller patches. To help us
remember this still next week, add 'RFC' to the patch subject and write
the commit or cover letter message to indicate that you are asking for
input in splitting up this patch.
Post by Mylene JOSSERAND
I tried to follow the coding style and I checked the code with
checkpatch.pl script from Linux kernel. I hope it will be okay.
Kernel coding style is mostly ok, we'll do any additional nitpicking
after or during split up. I'd concentrate more on the patch splitting
first with nitpicking later. Causes one more round, but is probably less
confusing this way.
Post by Mylene JOSSERAND
I will send the patch in next few days. It will be the first version
so do not hesitate for any comments. I would send a version 2 with
pleasure.
Thanks!

Patrik
Mylene Josserand
2015-10-02 06:12:55 UTC
Permalink
Hi Patrik,

Thank you for your quick answer and your help.
Post by Patrik Flykt
Post by Mylene Josserand
Post by Mylene JOSSERAND
Post by Tomasz Bursztyka
Hi Mylene,
Post by Mylene JOSSERAND
I understand and see (in outline) how adapt the code.
Thank you for the tips, it will help me a lot if the Frederik solution's did not
work for me.
Looks like Frederik's solution works with either context A or context B, not
both at same time.
Anyway, if you get a patch that works, you will be welcomed to send it on this ML.
Okay, I will let you know if I managed to get it work.
Sorry for my (very) late answer.
We're fine with a bit longer real world schedules, no worries here.
Post by Mylene Josserand
I have managed to handle two (or more) internet contexts at the same
time, 2-3 days after my last post but I was busy so I did not have
time to send a patch.
I have implemented it (and tested it) with version 1.29. I am
currently merging it to the last version of connman.
There are many modifications and I do not really know how I should
categorize them into patches series. As I removed the "network"
property in modem_data and added it into context_data, there are many
functions that are impacted.
Ideally it should be be possible to present this kind of major
structural change with moving data from one structure to another by
creating a bigger patch that does only that with no loss of
functionality. Out of necessity this patch then touches quite many
places at the same time. Ideally the next (or previous) patch(es) in the
series would then add the desired feature change(s). But as you propose
below,...
Okay, I understand.
Post by Patrik Flykt
Post by Mylene Josserand
If it is okay for you, I thought I could send one patch with all
modifications and if there is a way to categorize, you could report it
to me.
...you can also send one big patch where we can help you categorizing
and splitting up the functionality into smaller patches. To help us
remember this still next week, add 'RFC' to the patch subject and write
the commit or cover letter message to indicate that you are asking for
input in splitting up this patch.
I think I found 3 "categories" so I will send a patch series (but I will add the RFC flag as I am not sure about it).
Post by Patrik Flykt
Post by Mylene Josserand
I tried to follow the coding style and I checked the code with
checkpatch.pl script from Linux kernel. I hope it will be okay.
Kernel coding style is mostly ok, we'll do any additional nitpicking
after or during split up. I'd concentrate more on the patch splitting
first with nitpicking later. Causes one more round, but is probably less
confusing this way.
Okay, it is fine for me.


Thank you !

Mylène

Loading...