Hi Patrik,

Thank you for your quick answer and your help.


> On Wed, 2015-09-30 at 17:13 +0200, Mylene Josserand wrote:
>> > On 05/13/2015 01:10 PM, Tomasz Bursztyka wrote:
>> >> Hi Mylene,
>> >>
>> >>> 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.
> 
>> 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.



>>  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).


> 
>> 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
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman

Reply via email to