Re: [Xenomai] [RFC] Xenomai3 tuneables replaced by environment variables

[Philippe Gerum <rpm@xenomai.org>]

On 08/21/2017 01:12 PM, Henning Schild wrote:
> Am Wed, 16 Aug 2017 20:13:34 +0200
> schrieb Philippe Gerum <rpm@xenomai.org>:
> 
>> On 08/08/2017 09:27 PM, Henning Schild wrote:
>>>   
>>>> Could you sketch the requirements of the app with respect to
>>>> option parsing (namespace left aside)? Is there some main
>>>> non-Xenomai executable dlopening a Xenomai-based solib defining a
>>>> set of rt-specific options?  
>>>
>>> Yes the application runs its own main() and later dlopen() s
>>> multiple libs, some of which may be linked to xenomai. The order of
>>> the dlopens seems hard to control because of static c++
>>> constructors or something alike. But i suggest we discuss the
>>> internals of that particular app after we have finished the
>>> discussion. 
>>
>> No need for this; I was not asking for details about the internals,
>> only for explicit requirements about receiving parameters / options
>> among the software components present in your app. Anyway, I think I
>> figured it out from what you've just said.
>>
>>>> It seems that you are implicitly referring to ancillaries settings
>>>> such as --silent, --verbose and --quiet as being problematic. Is it
>>>> correct or are you referring to other parameters?  
>>>
>>> If your main comes before xenomai_init() it either has to be able to
>>> ignore xenomai args or it will need to change argv/argc before
>>> dlopening.
>>>
>>> In the first case it has to know all valid args  
>>
>> ... the application accepts. Do some (non-Xenomai) dlopened libs
>> define their own option namespace the main component does not know
>> about? If not, this is only a matter of excluding/ignoring the
>> options which the application does not accept when parsing the
>> argument vector.
>>
>> xenomai_init() will do the same afterwards, ignoring the non-Xenomai
>> options transparently. The point being: who should call xenomai_init()
>> in the plugin.so file, and when.
> 
> That basically means that you can not build a very robust parser. The
> problem i see here is a typo in an otherwise valid argument. Both
> xenomai and the application will happily ignore it, creating the
> impression that it was applied.
> 

The parsing sequence is ordered: first the app, then xenomai. If some
arg is left in the argument vector returned by xenomai_init(), then such
arg must be wrong. Turn off the auto-bootstrap feature, providing your
own library constructor for the plugin module, call xenomai_init()
manually there, checking for the output vector, and there will be no
robustness issue.

-- 
Philippe.