Re: Plugin infrastructure

2018-02-05 Thread Slava Monich

On 05/02/18 20:55, Jonas Bonn wrote:


On 02/05/2018 05:25 PM, Slava Monich wrote:

Hi Jonas,

On 02/04/2018 11:19 AM, Jonas Bonn wrote:

Hi,

I was reading through the ofono code and I see that there's a lot 
of code in place to support external plugins.  As things currently 
stand, however, ofono can only be built with _builtin_ modules, so 
all this plugin infrastructure is totally unused. So I had a couple 
of questions about this:


i)  Is there any value in keeping the plugin infrastructure in 
place? ...or would an effort to remove it be valued?


We did (still do?) have external plugins in use...


Yes, we do!


OK.  If you don't mind a stupid question:  why?  Why not just put 
these in the ofono tree?


Those are of no interest to the general public and not even compatible 
with the upstream - our fork is slightly different.


We wanted those to only be installed (pulled in via rpm dependencies) if 
the corresponding functionality is installed on the phone and 
dynamically loadable plugins fit quite nicely into the picture.


-Slava

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono


Re: Plugin infrastructure

2018-02-05 Thread Jonas Bonn

On 02/05/2018 05:25 PM, Slava Monich wrote:

Hi Jonas,

On 02/04/2018 11:19 AM, Jonas Bonn wrote:

Hi,

I was reading through the ofono code and I see that there's a lot of 
code in place to support external plugins.  As things currently 
stand, however, ofono can only be built with _builtin_ modules, so 
all this plugin infrastructure is totally unused. So I had a couple 
of questions about this:


i)  Is there any value in keeping the plugin infrastructure in place? 
...or would an effort to remove it be valued?


We did (still do?) have external plugins in use...


Yes, we do!


OK.  If you don't mind a stupid question:  why?  Why not just put these 
in the ofono tree?


/Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono


Re: Plugin infrastructure

2018-02-05 Thread Slava Monich

Hi Jonas,

On 02/04/2018 11:19 AM, Jonas Bonn wrote:

Hi,

I was reading through the ofono code and I see that there's a lot of 
code in place to support external plugins.  As things currently 
stand, however, ofono can only be built with _builtin_ modules, so 
all this plugin infrastructure is totally unused. So I had a couple 
of questions about this:


i)  Is there any value in keeping the plugin infrastructure in place? 
...or would an effort to remove it be valued?


We did (still do?) have external plugins in use...


Yes, we do!

If upstream eliminates the plugin system, we would still have to 
maintain it in our fork. At the moment we are using it more or less as is.


Cheers,
-Slava
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono


Re: Plugin infrastructure

2018-02-05 Thread Denis Kenzior

Hi Jonas,

On 02/04/2018 11:19 AM, Jonas Bonn wrote:

Hi,

I was reading through the ofono code and I see that there's a lot of 
code in place to support external plugins.  As things currently stand, 
however, ofono can only be built with _builtin_ modules, so all this 
plugin infrastructure is totally unused.  So I had a couple of questions 
about this:


i)  Is there any value in keeping the plugin infrastructure in place? 
...or would an effort to remove it be valued?


We did (still do?) have external plugins in use...



ii)  Does anyone actually use the include/exclude module patterns to 
prevent "plugins" (modules) from being automatically loaded?


yes...



I could imagine marking all module init/exit functions with GCC 
attributes "constructor/destructor" and have them automatically and 
unconditionally initialized at startup.  This would, however, render the 
exclude pattern option useless...


iii) Of course, using GCC attributes ties the project closer to one 
compiler which gives rise to another question.  What are the platforms 
that Ofono aims to support today?  Just Linux?  Linux and others that 
work by chance by virtue of being compatible?  Others?




From the beginning oFono was designed to be Linux only.  This allows us 
to use Linux specific features and not worry about weird OS abstractions.


Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono


Plugin infrastructure

2018-02-04 Thread Jonas Bonn

Hi,

I was reading through the ofono code and I see that there's a lot of 
code in place to support external plugins.  As things currently stand, 
however, ofono can only be built with _builtin_ modules, so all this 
plugin infrastructure is totally unused.  So I had a couple of questions 
about this:


i)  Is there any value in keeping the plugin infrastructure in place? 
...or would an effort to remove it be valued?


ii)  Does anyone actually use the include/exclude module patterns to 
prevent "plugins" (modules) from being automatically loaded?


I could imagine marking all module init/exit functions with GCC 
attributes "constructor/destructor" and have them automatically and 
unconditionally initialized at startup.  This would, however, render the 
exclude pattern option useless...


iii) Of course, using GCC attributes ties the project closer to one 
compiler which gives rise to another question.  What are the platforms 
that Ofono aims to support today?  Just Linux?  Linux and others that 
work by chance by virtue of being compatible?  Others?


Thanks,
Jonas
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono