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

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

[Henning Schild]

Hey,

xenomai3 has its tuneables and they can be set with command-line
parameters and setup_descriptors.

1.
The command-line parameters impose on the application, it has to be
modified to skip/ignore them. And ultimately it has to keep a list of
valid ones to do so pedanticly. If there are name clashes behaviour is
unclear. i.e. "--help" ld.so vs. dlopen

2.
The setup_descriptors do work but they rely on getting the order
stricly right. They have to execute before the first xenomai_init(). In
complex applications with multithreaded init using dlopen() and
auto-init-solib that quickly turns out to be unusable.

Suggestions:
1.
1.1 completely drop the support for parameters and the fiddling
    with /proc/cmdline
1.2 or agree on a prefix "--xeno-" so the application can ignore all
    xenomai parameters without knowing all

2.
2.1 completely drop the setup_descriptors in favour of environment
    variables

That would be a drastic change but i think we should do something about
it. With environment variables it is clear what happens without messing
with the applications init or parameters, getting rid of confusing
complexity.

Please let me know what you think, i would be happy to prepare patches.

Henning

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

[Philippe Gerum]

On 08/08/2017 11:23 AM, Henning Schild wrote:
> Hey,
>
> xenomai3 has its tuneables and they can be set with command-line
> parameters and setup_descriptors.
>
> 1.
> The command-line parameters impose on the application, it has to be
> modified to skip/ignore them.

No, the core takes care of this. I'm unsure what your application does 
to hit any conflict of that kind.

  And ultimately it has to keep a list of
> valid ones to do so pedanticly. If there are name clashes behaviour is
> unclear. i.e. "--help" ld.so vs. dlopen
>

--help can be extended. See how testsuite/latency does for an example.

> 2.
> The setup_descriptors do work but they rely on getting the order
> stricly right. They have to execute before the first xenomai_init(). In
> complex applications with multithreaded init using dlopen() and
> auto-init-solib that quickly turns out to be unusable.
>

Well, I've been using setup descriptors on quite complex customer 
applications (including lots of C++ static constructor braindamage), and 
never went into any dead end like you seem to imply since the latest 
additions in 3.0.5. Descriptors have their own priorities, and you may 
now use auto-bootstrappable libs as well.

> Suggestions:
> 1.
> 1.1 completely drop the support for parameters and the fiddling
>     with /proc/cmdline
> 1.2 or agree on a prefix "--xeno-" so the application can ignore all
>     xenomai parameters without knowing all
>
> 2.
> 2.1 completely drop the setup_descriptors in favour of environment
>     variables
>

Hell no. Environment variables are crap. Unlike options which are 
explicit, those things tend to pollute some hidden namespace, staying 
there long after you stopped expecting them having any influence, set by 
dusty login scripts. That one is a strict nak for me, sorry.

> That would be a drastic change but i think we should do something about
> it. With environment variables it is clear what happens without messing
> with the applications init or parameters, getting rid of confusing
> complexity.
>
> Please let me know what you think, i would be happy to prepare patches.
>

What is the exact problem you face regarding options? Please also 
remember that influencing the whole argument system only to support a 
quite infrequent use case such as dlopen() is not the way to go. It's ok 
to find a solution that might fit all usages, it is not to introduce 
stuff that eases 1% of the use cases which badly affects 99% of the rest.


PS: I'm supposedly off line at the moment, so follow ups may take some 
time to appear.

-- 
Philippe.

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

[Jan Kiszka]

On 2017-08-08 06:24, Philippe Gerum wrote:
> On 08/08/2017 11:23 AM, Henning Schild wrote:
>> Hey,
>>
>> xenomai3 has its tuneables and they can be set with command-line
>> parameters and setup_descriptors.
>>
>> 1.
>> The command-line parameters impose on the application, it has to be
>> modified to skip/ignore them.
> 
> No, the core takes care of this. I'm unsure what your application does
> to hit any conflict of that kind.
> 
>  And ultimately it has to keep a list of
>> valid ones to do so pedanticly. If there are name clashes behaviour is
>> unclear. i.e. "--help" ld.so vs. dlopen
>>
> 
> --help can be extended. See how testsuite/latency does for an example.
> 
>> 2.
>> The setup_descriptors do work but they rely on getting the order
>> stricly right. They have to execute before the first xenomai_init(). In
>> complex applications with multithreaded init using dlopen() and
>> auto-init-solib that quickly turns out to be unusable.
>>
> 
> Well, I've been using setup descriptors on quite complex customer
> applications (including lots of C++ static constructor braindamage), and
> never went into any dead end like you seem to imply since the latest
> additions in 3.0.5. Descriptors have their own priorities, and you may
> now use auto-bootstrappable libs as well.
> 
>> Suggestions:
>> 1.
>> 1.1 completely drop the support for parameters and the fiddling
>>     with /proc/cmdline
>> 1.2 or agree on a prefix "--xeno-" so the application can ignore all
>>     xenomai parameters without knowing all
>>
>> 2.
>> 2.1 completely drop the setup_descriptors in favour of environment
>>     variables
>>
> 
> Hell no. Environment variables are crap. Unlike options which are
> explicit, those things tend to pollute some hidden namespace, staying
> there long after you stopped expecting them having any influence, set by
> dusty login scripts. That one is a strict nak for me, sorry.>
>> That would be a drastic change but i think we should do something about
>> it. With environment variables it is clear what happens without messing
>> with the applications init or parameters, getting rid of confusing
>> complexity.
>>
>> Please let me know what you think, i would be happy to prepare patches.
>>
> 
> What is the exact problem you face regarding options? Please also
> remember that influencing the whole argument system only to support a
> quite infrequent use case such as dlopen() is not the way to go. It's ok
> to find a solution that might fit all usages, it is not to introduce
> stuff that eases 1% of the use cases which badly affects 99% of the rest.
> 

Environment variables are the standard way of injecting information into
applications that are - at most - partially aware of additional
parameters. Example: proxy settings (http_proxy & Co.). They provide a
clean by-pass of any code that does not expect "gaining" additional
parameters in other ways. All we need to do here is to create a separate
namespace in the environment by prefixing everything that Xenomai needs.

In contrast, command line parameter injecting is very messy because

- there is no standard way of parsing them

- there is no standard way of formatting or clustering them

If your application is not written for Xenomai, maybe only pulls in this
dependency by linking against / dlopen'ing a library, all the problems
start that we see, and you need to fiddle with constructors, priorities,
manual initialization, you-name-it.

I admit removing the command line way of configuring Xenomai libs is not
desirable for existing application, but I would strongly recommend
fixing the defaults: command line params should become opt-in while env
vars the recommend default because they work in all cases.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

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

[Henning Schild]

Am Tue, 8 Aug 2017 12:24:54 +0200
schrieb Philippe Gerum <rpm@xenomai.org>:

> On 08/08/2017 11:23 AM, Henning Schild wrote:
> > Hey,
> >
> > xenomai3 has its tuneables and they can be set with command-line
> > parameters and setup_descriptors.
> >
> > 1.
> > The command-line parameters impose on the application, it has to be
> > modified to skip/ignore them.  
> 
> No, the core takes care of this. I'm unsure what your application
> does to hit any conflict of that kind.

dlopen() so main will see arguments meant for xenomai_init() or you
need to no_auto_init and fiddle with /proc/cmdline and call xenomai_init

>   And ultimately it has to keep a list of
> > valid ones to do so pedanticly. If there are name clashes behaviour
> > is unclear. i.e. "--help" ld.so vs. dlopen
> >  
> 
> --help can be extended. See how testsuite/latency does for an example.

Help was just one example, you could have the same problem with any of
the other parameters.

> > 2.
> > The setup_descriptors do work but they rely on getting the order
> > stricly right. They have to execute before the first
> > xenomai_init(). In complex applications with multithreaded init
> > using dlopen() and auto-init-solib that quickly turns out to be
> > unusable. 
> 
> Well, I've been using setup descriptors on quite complex customer 
> applications (including lots of C++ static constructor braindamage),
> and never went into any dead end like you seem to imply since the
> latest additions in 3.0.5. Descriptors have their own priorities, and
> you may now use auto-bootstrappable libs as well.

I did not. I gave my customer multiple examples on how to set
mem-pool-size in static, ld.so and dlopen(). They have braindamage
static c++ with dlopen() and could not make it work. At the moment
their main() ignores any unknown argument so they can use 1. but that
needs to be fixed.

> > Suggestions:
> > 1.
> > 1.1 completely drop the support for parameters and the fiddling
> >     with /proc/cmdline
> > 1.2 or agree on a prefix "--xeno-" so the application can ignore all
> >     xenomai parameters without knowing all

You did not comment on that at all.

> > 2.
> > 2.1 completely drop the setup_descriptors in favour of environment
> >     variables
> >  
> 
> Hell no. Environment variables are crap. Unlike options which are 
> explicit, those things tend to pollute some hidden namespace, staying 
> there long after you stopped expecting them having any influence, set
> by dusty login scripts. That one is a strict nak for me, sorry.

Ok, that is a clear opinion and i get it. Let us not discuss env
variables anymore, but let us keep talking under that thread title ;).

> > That would be a drastic change but i think we should do something
> > about it. With environment variables it is clear what happens
> > without messing with the applications init or parameters, getting
> > rid of confusing complexity.
> >
> > Please let me know what you think, i would be happy to prepare
> > patches. 
> 
> What is the exact problem you face regarding options? Please also 
> remember that influencing the whole argument system only to support a 
> quite infrequent use case such as dlopen() is not the way to go. It's
> ok to find a solution that might fit all usages, it is not to
> introduce stuff that eases 1% of the use cases which badly affects
> 99% of the rest.

My customer switched to xenomai3 and they did not manage to set the
tuneables without hacks. I looked into setting them and found that
there are different ways and different behaviours for these ways
depending on how you link. They could not make it work ... Ok i can fix
it for them without talking to the community.

But i can do something about the fact that it is too complicated, and
that is what i am trying to do with this mail.

I would like to see only one way that always works the same no matter
how you link, no questions about who wins when multiple want to tune.
Maybe we can drop the "--auto-init-solib" switch eventually and just
make it default.

Imho 33% of the linking cases are broken, true that dlopen() is
probably not used a lot.

Henning

> PS: I'm supposedly off line at the moment, so follow ups may take
> some time to appear.
> 

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

[Philippe Gerum]

On 08/08/2017 01:48 PM, Henning Schild wrote:
> Am Tue, 8 Aug 2017 12:24:54 +0200
> schrieb Philippe Gerum <rpm@xenomai.org>:
>> No, the core takes care of this. I'm unsure what your application
>> does to hit any conflict of that kind.
>
> dlopen() so main will see arguments meant for xenomai_init() or you
> need to no_auto_init and fiddle with /proc/cmdline and call xenomai_init
>

At any rate, you do not need to fiddle with /proc/cmdline manually, really.

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?

>>   And ultimately it has to keep a list of
>>> valid ones to do so pedanticly. If there are name clashes behaviour
>>> is unclear. i.e. "--help" ld.so vs. dlopen
>>>
>>
>> --help can be extended. See how testsuite/latency does for an example.
>
> Help was just one example, you could have the same problem with any of
> the other parameters.

I don't see any reason to override any other core parameter, beyond 
--help which should remain as generic as possible but still allowing for 
all software layers existing in the application to contribute to it. 
--xeno-help would not make any sense.

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?

>
>>> 2.
>>> The setup_descriptors do work but they rely on getting the order
>>> stricly right. They have to execute before the first
>>> xenomai_init(). In complex applications with multithreaded init
>>> using dlopen() and auto-init-solib that quickly turns out to be
>>> unusable.
>>
>> Well, I've been using setup descriptors on quite complex customer
>> applications (including lots of C++ static constructor braindamage),
>> and never went into any dead end like you seem to imply since the
>> latest additions in 3.0.5. Descriptors have their own priorities, and
>> you may now use auto-bootstrappable libs as well.
>
> I did not. I gave my customer multiple examples on how to set
> mem-pool-size in static, ld.so and dlopen(). They have braindamage
> static c++ with dlopen() and could not make it work. At the moment
> their main() ignores any unknown argument so they can use 1. but that
> needs to be fixed.
>

The application may have to be fixed, I agree. Tunables provide a safer 
way to wire settings compared to environment variables. If settings need 
frequent updates, then environment variables are not practical at all.

If the issue is with calling Xenomai services from static ctors, then I 
can describe a way to do this. If other requirements exist along this 
one, please let me know.

>>> Suggestions:
>>> 1.
>>> 1.1 completely drop the support for parameters and the fiddling
>>>     with /proc/cmdline
>>> 1.2 or agree on a prefix "--xeno-" so the application can ignore all
>>>     xenomai parameters without knowing all
>
 > You did not comment on that at all.
 >

Because this is asking for Xenomai not to use a few generic options 
names for common ancillary services, leaving it to the application, 
which I see no reason for. Leaving generic names to the core makes sense 
as much as the opposite.

>>> 2.
>>> 2.1 completely drop the setup_descriptors in favour of environment
>>>     variables
>>>
>>
>> Hell no. Environment variables are crap. Unlike options which are
>> explicit, those things tend to pollute some hidden namespace, staying
>> there long after you stopped expecting them having any influence, set
>> by dusty login scripts. That one is a strict nak for me, sorry.
>
> Ok, that is a clear opinion and i get it. Let us not discuss env
> variables anymore, but let us keep talking under that thread title ;).
>

No issue with that.

>>> That would be a drastic change but i think we should do something
>>> about it. With environment variables it is clear what happens
>>> without messing with the applications init or parameters, getting
>>> rid of confusing complexity.
>>>
>>> Please let me know what you think, i would be happy to prepare
>>> patches.
>>
>> What is the exact problem you face regarding options? Please also
>> remember that influencing the whole argument system only to support a
>> quite infrequent use case such as dlopen() is not the way to go. It's
>> ok to find a solution that might fit all usages, it is not to
>> introduce stuff that eases 1% of the use cases which badly affects
>> 99% of the rest.
>
> My customer switched to xenomai3 and they did not manage to set the
> tuneables without hacks. I looked into setting them and found that
> there are different ways and different behaviours for these ways
> depending on how you link. They could not make it work ... Ok i can fix
> it for them without talking to the community.
>
> But i can do something about the fact that it is too complicated, and
> that is what i am trying to do with this mail.
>
> I would like to see only one way that always works the same no matter
> how you link, no questions about who wins when multiple want to tune.
> Maybe we can drop the "--auto-init-solib" switch eventually and just
> make it default.
>

Frankly, that seems a legitimate goal, but with C++ and static ctors in 
the picture, I don't see any one-fits-it-all solution. But there is no 
reason not to try finding one again.

> Imho 33% of the linking cases are broken, true that dlopen() is
> probably not used a lot.
>

Not to speak of the fact that it introduces its own set of linking 
issues (scope mess, late binding conflicts etc). I would usually use 
that only for pure plugin architectures with fairly simple content 
interfaces; I don't see any other situation that would legitimately 
justify this.

-- 
Philippe.

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

[Henning Schild]

Am Tue, 8 Aug 2017 20:05:07 +0200
schrieb Philippe Gerum <rpm@xenomai.org>:

> On 08/08/2017 01:48 PM, Henning Schild wrote:
> > Am Tue, 8 Aug 2017 12:24:54 +0200
> > schrieb Philippe Gerum <rpm@xenomai.org>:  
> >> No, the core takes care of this. I'm unsure what your application
> >> does to hit any conflict of that kind.  
> >
> > dlopen() so main will see arguments meant for xenomai_init() or you
> > need to no_auto_init and fiddle with /proc/cmdline and call
> > xenomai_init 
> 
> At any rate, you do not need to fiddle with /proc/cmdline manually,
> really.

True you construct the argv and call xenomai_init().

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

> 
> >>   And ultimately it has to keep a list of  
> >>> valid ones to do so pedanticly. If there are name clashes
> >>> behaviour is unclear. i.e. "--help" ld.so vs. dlopen
> >>>  
> >>
> >> --help can be extended. See how testsuite/latency does for an
> >> example.  
> >
> > Help was just one example, you could have the same problem with any
> > of the other parameters.  
> 
> I don't see any reason to override any other core parameter, beyond 
> --help which should remain as generic as possible but still allowing
> for all software layers existing in the application to contribute to
> it. --xeno-help would not make any sense.
>
> 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 and the second one
does not sound very nice. And for the second one i am not sure there is
always a time window in the face of static ctors launching threads and
dlopening.
 
> >  
> >>> 2.
> >>> The setup_descriptors do work but they rely on getting the order
> >>> stricly right. They have to execute before the first
> >>> xenomai_init(). In complex applications with multithreaded init
> >>> using dlopen() and auto-init-solib that quickly turns out to be
> >>> unusable.  
> >>
> >> Well, I've been using setup descriptors on quite complex customer
> >> applications (including lots of C++ static constructor
> >> braindamage), and never went into any dead end like you seem to
> >> imply since the latest additions in 3.0.5. Descriptors have their
> >> own priorities, and you may now use auto-bootstrappable libs as
> >> well.  
> >
> > I did not. I gave my customer multiple examples on how to set
> > mem-pool-size in static, ld.so and dlopen(). They have braindamage
> > static c++ with dlopen() and could not make it work. At the moment
> > their main() ignores any unknown argument so they can use 1. but
> > that needs to be fixed.
> >  
> 
> The application may have to be fixed, I agree. Tunables provide a
> safer way to wire settings compared to environment variables. If
> settings need frequent updates, then environment variables are not
> practical at all.
> 
> If the issue is with calling Xenomai services from static ctors, then
> I can describe a way to do this. If other requirements exist along
> this one, please let me know.

Yes might be, but let discuss after we have concluded on the "there
should be one way that always works".

> >>> Suggestions:
> >>> 1.
> >>> 1.1 completely drop the support for parameters and the fiddling
> >>>     with /proc/cmdline
> >>> 1.2 or agree on a prefix "--xeno-" so the application can ignore
> >>> all xenomai parameters without knowing all  
> >
>  > You did not comment on that at all.
>  >  
> 
> Because this is asking for Xenomai not to use a few generic options 
> names for common ancillary services, leaving it to the application, 
> which I see no reason for. Leaving generic names to the core makes
> sense as much as the opposite.

1.1 suggests dropping but 1.2 suggests a name convention to ease parsing

> >>> 2.
> >>> 2.1 completely drop the setup_descriptors in favour of environment
> >>>     variables
> >>>  
> >>
> >> Hell no. Environment variables are crap. Unlike options which are
> >> explicit, those things tend to pollute some hidden namespace,
> >> staying there long after you stopped expecting them having any
> >> influence, set by dusty login scripts. That one is a strict nak
> >> for me, sorry.  
> >
> > Ok, that is a clear opinion and i get it. Let us not discuss env
> > variables anymore, but let us keep talking under that thread
> > title ;). 
> 
> No issue with that.
> 
> >>> That would be a drastic change but i think we should do something
> >>> about it. With environment variables it is clear what happens
> >>> without messing with the applications init or parameters, getting
> >>> rid of confusing complexity.
> >>>
> >>> Please let me know what you think, i would be happy to prepare
> >>> patches.  
> >>
> >> What is the exact problem you face regarding options? Please also
> >> remember that influencing the whole argument system only to
> >> support a quite infrequent use case such as dlopen() is not the
> >> way to go. It's ok to find a solution that might fit all usages,
> >> it is not to introduce stuff that eases 1% of the use cases which
> >> badly affects 99% of the rest.  
> >
> > My customer switched to xenomai3 and they did not manage to set the
> > tuneables without hacks. I looked into setting them and found that
> > there are different ways and different behaviours for these ways
> > depending on how you link. They could not make it work ... Ok i can
> > fix it for them without talking to the community.
> >
> > But i can do something about the fact that it is too complicated,
> > and that is what i am trying to do with this mail.
> >
> > I would like to see only one way that always works the same no
> > matter how you link, no questions about who wins when multiple want
> > to tune. Maybe we can drop the "--auto-init-solib" switch
> > eventually and just make it default.
> >  
> 
> Frankly, that seems a legitimate goal, but with C++ and static ctors
> in the picture, I don't see any one-fits-it-all solution. But there
> is no reason not to try finding one again.

I suggested one but promised to not bring it up again ;). Any other
ideas?
 
> > Imho 33% of the linking cases are broken, true that dlopen() is
> > probably not used a lot.
> >  
> 
> Not to speak of the fact that it introduces its own set of linking 
> issues (scope mess, late binding conflicts etc). I would usually use 
> that only for pure plugin architectures with fairly simple content 
> interfaces; I don't see any other situation that would legitimately 
> justify this.

My customers use it to have two versions of their app. A xenomai and a
non-xenomai version and the switch is in dlopening another lib. As far
as i know the non-xeno version is for basic testing on a regular Linux
and in simulation/virtualization. And the whole setup would
theoretically allow to switch the realtime provider without touching
the app.
I personally dont like it but just so you have some context.

Henning

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

[Philippe Gerum]

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.

 and the second one
> does not sound very nice. And for the second one i am not sure there is
> always a time window in the face of static ctors launching threads and
> dlopening.

That is not an issue if Xenomai setup descriptors are used properly. The
"tuning" phase which may override parameters always precedes the "init"
phase which considers them when allocating and bootstrapping the resources.

Practically: say you have plugin.so, explicitly set dependent on
libcobalt.so at link time, you will nevertheless have all ->tune()
handlers run first, before the first ->init() handler is invoked. And
this will happen only when xenomai_init() is called; all despite the
fact that solibs are initialized in reverse dependency order (i.e. from
the least dependent lib to the most dependent one).

So, the way that should work with your app would be to load a proxy
solib which was made dependent on libcobalt.so at build time. That proxy
shared lib would define a setup descriptor, whose ->tune() handler could
pull values from the environment for setting whatever runtime/config
Xenomai tunable that one sees fit. That process is guaranteed to happen
_before_ the Xenomai core is initialized. The proxy solib would include
a Xenomai bootstrap module, calling xenomai_init().

The entire process would then look like:

- main() entered
-- application parses argv[], no Xenomai arg in the way
...
-- dlopen(plugin.so)
--- libcobalt.so dependency is loaded, all setup descriptors registered
--- libplugin.so is loaded, setup descriptor registered
--- libplugin's bootstrap module calls xenomai_init_dso()
---- plugin->tune() is called, pulls args from the environment
---- Xenomai ->init() handlers run (using arg settings)
-- back to main()

With all Xenomai base parameters exclusively pulled from the
environment, you could omit any Xenomai-specific option switch from the
command line when spawning the app, reserving the entire option
namespace to the application.

I have demoed this in the attached code (the proxy lib is implemented by
plugin.c). The demo code only retrieves the verbosity_level parameter
from the environment, which is normally affected by --silent, --quiet
and --verbose command line options, but you get the idea.

I understand you would like a permanent way of doing this without having
to provide any code. Although I don't buy a second the argument about
envvars being "more standard" than command switches, I'm not opposed to
get this kind of feature in, but only if:

- the implementation does not reinvent the wheel of parameter parsing,
this would be fairly silly.
- the natural way of setting Xenomai parameters remains based on command
line switches. Most people do NOT care a dime about deferred binding to
libcobalt, so there is no reason to make this use case the preferred one.

The sanest way to provide such feature would be to implicitly turn every
option label defined by setup descriptors into a potential envvar, e.g.
--cpu-affinity would be unambiguously matched by a variable named
"cpu_affinity". The core would look for such a variable in the
environment if the command line switch is not found, hence giving
precedence to the latter implicitly.

At least, this would limit the risk of having totally unrelated ways of
setting core parameters, with less braindamage side-effects on people
with unsuitable daily amount of caffeine for the job.

There is a way to do this properly, but this cannot be high on my todo
list ATM, given the ongoing work I have on my plate. Anyway, issue logged.

-- 
Philippe.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugin.c
Type: text/x-csrc
Size: 556 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20170816/580e7aa4/attachment.c>
-------------- next part --------------

ifeq ($(XENO_CONFIG),)
XENO_CONFIG=xeno-config
endif

prefix := $(shell DESTDIR=$(DESTDIR) $(XENO_CONFIG) --prefix)

ifeq ($(prefix),)
$(error Please add <xenomai-install-path>/bin to your PATH variable or specify DESTDIR)
endif

libdir := $(shell DESTDIR=$(DESTDIR) $(XENO_CONFIG) --libdir)
RPATH=$(libdir)
CFLAGS  := $(shell DESTDIR=$(DESTDIR) $(XENO_CONFIG) --posix --cflags)
LDFLAGS := $(shell DESTDIR=$(DESTDIR) $(XENO_CONFIG) --posix --ldflags --auto-init-solib)

all: libplugin.so main

libplugin.so: plugin.c
	$(CROSS_COMPILE)$(CC) $(CFLAGS) -fPIC -c $<
	$(CROSS_COMPILE)$(CC) -shared -Wl,-soname,libplugin.so.0 -o libplugin.so.0.0.0 plugin.o $(LDFLAGS) -Wl,-rpath=$(RPATH) -Wl,--export-dynamic
	ln -sf libplugin.so.0.0.0 libplugin.so.0
	ln -sf libplugin.so.0.0.0 libplugin.so

main: main.c
	$(CROSS_COMPILE)$(CC) -o $@ $< -lpthread -lrt -ldl

clean:
	$(RM) main libplugin.so.0*
-------------- next part --------------
A non-text attachment was scrubbed...
Name: main.c
Type: text/x-csrc
Size: 400 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20170816/580e7aa4/attachment-0001.c>

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

[Henning Schild]

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.

Thanks for the code examples and long explanation.

Henning

>  and the second one
> > does not sound very nice. And for the second one i am not sure
> > there is always a time window in the face of static ctors launching
> > threads and dlopening.  
> 
> That is not an issue if Xenomai setup descriptors are used properly.
> The "tuning" phase which may override parameters always precedes the
> "init" phase which considers them when allocating and bootstrapping
> the resources.
> 
> Practically: say you have plugin.so, explicitly set dependent on
> libcobalt.so at link time, you will nevertheless have all ->tune()
> handlers run first, before the first ->init() handler is invoked. And
> this will happen only when xenomai_init() is called; all despite the
> fact that solibs are initialized in reverse dependency order (i.e.
> from the least dependent lib to the most dependent one).
> 
> So, the way that should work with your app would be to load a proxy
> solib which was made dependent on libcobalt.so at build time. That
> proxy shared lib would define a setup descriptor, whose ->tune()
> handler could pull values from the environment for setting whatever
> runtime/config Xenomai tunable that one sees fit. That process is
> guaranteed to happen _before_ the Xenomai core is initialized. The
> proxy solib would include a Xenomai bootstrap module, calling
> xenomai_init().
> 
> The entire process would then look like:
> 
> - main() entered
> -- application parses argv[], no Xenomai arg in the way
> ...
> -- dlopen(plugin.so)
> --- libcobalt.so dependency is loaded, all setup descriptors
> registered --- libplugin.so is loaded, setup descriptor registered
> --- libplugin's bootstrap module calls xenomai_init_dso()
> ---- plugin->tune() is called, pulls args from the environment
> ---- Xenomai ->init() handlers run (using arg settings)
> -- back to main()
> 
> With all Xenomai base parameters exclusively pulled from the
> environment, you could omit any Xenomai-specific option switch from
> the command line when spawning the app, reserving the entire option
> namespace to the application.
> 
> I have demoed this in the attached code (the proxy lib is implemented
> by plugin.c). The demo code only retrieves the verbosity_level
> parameter from the environment, which is normally affected by
> --silent, --quiet and --verbose command line options, but you get the
> idea.
> 
> I understand you would like a permanent way of doing this without
> having to provide any code. Although I don't buy a second the
> argument about envvars being "more standard" than command switches,
> I'm not opposed to get this kind of feature in, but only if:
> 
> - the implementation does not reinvent the wheel of parameter parsing,
> this would be fairly silly.
> - the natural way of setting Xenomai parameters remains based on
> command line switches. Most people do NOT care a dime about deferred
> binding to libcobalt, so there is no reason to make this use case the
> preferred one.
> 
> The sanest way to provide such feature would be to implicitly turn
> every option label defined by setup descriptors into a potential
> envvar, e.g. --cpu-affinity would be unambiguously matched by a
> variable named "cpu_affinity". The core would look for such a
> variable in the environment if the command line switch is not found,
> hence giving precedence to the latter implicitly.
> 
> At least, this would limit the risk of having totally unrelated ways
> of setting core parameters, with less braindamage side-effects on
> people with unsuitable daily amount of caffeine for the job.
> 
> There is a way to do this properly, but this cannot be high on my todo
> list ATM, given the ongoing work I have on my plate. Anyway, issue
> logged.
> 

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

[Philippe Gerum]

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.

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

[Henning Schild]

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.
> 
>  and the second one
> > does not sound very nice. And for the second one i am not sure
> > there is always a time window in the face of static ctors launching
> > threads and dlopening.  
> 
> That is not an issue if Xenomai setup descriptors are used properly.
> The "tuning" phase which may override parameters always precedes the
> "init" phase which considers them when allocating and bootstrapping
> the resources.
> 
> Practically: say you have plugin.so, explicitly set dependent on
> libcobalt.so at link time, you will nevertheless have all ->tune()
> handlers run first, before the first ->init() handler is invoked. And
> this will happen only when xenomai_init() is called; all despite the
> fact that solibs are initialized in reverse dependency order (i.e.
> from the least dependent lib to the most dependent one).
> 
> So, the way that should work with your app would be to load a proxy
> solib which was made dependent on libcobalt.so at build time. That
> proxy shared lib would define a setup descriptor, whose ->tune()
> handler could pull values from the environment for setting whatever
> runtime/config Xenomai tunable that one sees fit. That process is
> guaranteed to happen _before_ the Xenomai core is initialized. The
> proxy solib would include a Xenomai bootstrap module, calling
> xenomai_init().
> 
> The entire process would then look like:
> 
> - main() entered
> -- application parses argv[], no Xenomai arg in the way
> ...
> -- dlopen(plugin.so)
> --- libcobalt.so dependency is loaded, all setup descriptors
> registered --- libplugin.so is loaded, setup descriptor registered
> --- libplugin's bootstrap module calls xenomai_init_dso()
> ---- plugin->tune() is called, pulls args from the environment
> ---- Xenomai ->init() handlers run (using arg settings)
> -- back to main()
> 
> With all Xenomai base parameters exclusively pulled from the
> environment, you could omit any Xenomai-specific option switch from
> the command line when spawning the app, reserving the entire option
> namespace to the application.
> 
> I have demoed this in the attached code (the proxy lib is implemented
> by plugin.c). The demo code only retrieves the verbosity_level
> parameter from the environment, which is normally affected by
> --silent, --quiet and --verbose command line options, but you get the
> idea.

I only just really looked at the example, after i asked my customer to
look at your response. And they kept telling me that it will not work.

Now i gave them a similar example a few months ago. Put the tuning in
the lib init and you are done ...

As far as i understand the situation:
We are talking about more than one "plugin" that pulls in libcobalt.
And the dlopens are not in main but in static ctors before main, so our
plugin load order is "unknown/random". So the tuning would have to go
into all plugins or we will need to find a way to have a defined "first
plugin".

I guess we can invent libtune.so and LD_PRELOAD it. Or put that as
proxy into all plugins.  ... and all that vs "export XENO_foo"

> I understand you would like a permanent way of doing this without
> having to provide any code.

No, but i anticipated a discussion and decided to write code when the
outcome of the discussion is clear.

> Although I don't buy a second the argument about envvars being "more
> standard" than command switches,

Command switches always become a problem when two or more components
have to share the namespace. Removing your traces and not bothering
the other/imposing on the other only works if the order is known. In
Xenomai the order depends on how people link so we can not know it for
the general case.

I would not want to be the poor guy writing main() for an app where
multiple libs think that argv is for them to use, especially with
tricks to access it before main(). Just the fact that xenomai is
stealing this out of /proc/self/cmdline should suggest how non-standard
that is.

Env variables are just there to look at, if you are not interested
nobody will tell you to look at argc more of them. They survive a
fork() if your main script needs to launch multiple xenomai apps with
the same tuning.

> I'm not opposed to get this kind of feature in, but only if:
>
> - the implementation does not reinvent the wheel of parameter parsing,
> this would be fairly silly.
> - the natural way of setting Xenomai parameters remains based on
> command line switches. Most people do NOT care a dime about deferred
> binding to libcobalt, so there is no reason to make this use case the
> preferred one.

If we can not agree to drop at least the tunables, introducing another
way would be insane.
 
> The sanest way to provide such feature would be to implicitly turn
> every option label defined by setup descriptors into a potential
> envvar, e.g. --cpu-affinity would be unambiguously matched by a
> variable named "cpu_affinity". The core would look for such a
> variable in the environment if the command line switch is not found,
> hence giving precedence to the latter implicitly.

Yes the command line switch should still win, if they really need to
stay. And a prefix like XENO_ should be added.

> At least, this would limit the risk of having totally unrelated ways
> of setting core parameters, with less braindamage side-effects on
> people with unsuitable daily amount of caffeine for the job.
> 
> There is a way to do this properly, but this cannot be high on my todo
> list ATM, given the ongoing work I have on my plate. Anyway, issue
> logged.

Would you be willing to review/consider a patch that replaces the
tuneables with env vars?

Henning

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

[Philippe Gerum]

On 08/25/2017 07:16 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.
>>
>>  and the second one
>>> does not sound very nice. And for the second one i am not sure
>>> there is always a time window in the face of static ctors launching
>>> threads and dlopening.  
>>
>> That is not an issue if Xenomai setup descriptors are used properly.
>> The "tuning" phase which may override parameters always precedes the
>> "init" phase which considers them when allocating and bootstrapping
>> the resources.
>>
>> Practically: say you have plugin.so, explicitly set dependent on
>> libcobalt.so at link time, you will nevertheless have all ->tune()
>> handlers run first, before the first ->init() handler is invoked. And
>> this will happen only when xenomai_init() is called; all despite the
>> fact that solibs are initialized in reverse dependency order (i.e.
>> from the least dependent lib to the most dependent one).
>>
>> So, the way that should work with your app would be to load a proxy
>> solib which was made dependent on libcobalt.so at build time. That
>> proxy shared lib would define a setup descriptor, whose ->tune()
>> handler could pull values from the environment for setting whatever
>> runtime/config Xenomai tunable that one sees fit. That process is
>> guaranteed to happen _before_ the Xenomai core is initialized. The
>> proxy solib would include a Xenomai bootstrap module, calling
>> xenomai_init().
>>
>> The entire process would then look like:
>>
>> - main() entered
>> -- application parses argv[], no Xenomai arg in the way
>> ...
>> -- dlopen(plugin.so)
>> --- libcobalt.so dependency is loaded, all setup descriptors
>> registered --- libplugin.so is loaded, setup descriptor registered
>> --- libplugin's bootstrap module calls xenomai_init_dso()
>> ---- plugin->tune() is called, pulls args from the environment
>> ---- Xenomai ->init() handlers run (using arg settings)
>> -- back to main()
>>
>> With all Xenomai base parameters exclusively pulled from the
>> environment, you could omit any Xenomai-specific option switch from
>> the command line when spawning the app, reserving the entire option
>> namespace to the application.
>>
>> I have demoed this in the attached code (the proxy lib is implemented
>> by plugin.c). The demo code only retrieves the verbosity_level
>> parameter from the environment, which is normally affected by
>> --silent, --quiet and --verbose command line options, but you get the
>> idea.
> 
> I only just really looked at the example, after i asked my customer to
> look at your response. And they kept telling me that it will not work.

This sounds like nobody tried it actually.

> 
> Now i gave them a similar example a few months ago. Put the tuning in
> the lib init and you are done ...
> 
> As far as i understand the situation:
> We are talking about more than one "plugin" that pulls in libcobalt.
> And the dlopens are not in main but in static ctors before main, so our
> plugin load order is "unknown/random". So the tuning would have to go
> into all plugins or we will need to find a way to have a defined "first
> plugin".
> 

This explanation is very confusing. Unlike dlmopen(), dlopen()ing
multiple times the same shared object (and likewise its dependencies)
only creates a single mapping at the initial opening, and only runs the
library constructors once at that moment. This would include the call to
xenomai_init() if the bootstrap module is present in the DSO.

You could dlopen() libplugin.so directly or indirectly via the
dependency list a hundred times, you would only get a single bootstrap
if the bootstrap module is glued to the DSO. If not, then calling
xenomai_init() multiple times from your app would simply lead to nop
after the first call (with Xenomai 3.0.5).

> I guess we can invent libtune.so and LD_PRELOAD it. Or put that as
> proxy into all plugins.  ... and all that vs "export XENO_foo"
> 

I guess that your customer may want to clearly explain what they want to
achieve by sketching their init process and the software components in
the picture, because at this point, I could not figure out what their
problem is. I'm not keen on continuing this discussion only based on
guesses.

On a general note, I believe that this discussion took the wrong track
by mentioning orthogonal and often unrelated issues such as constructor
priority, dlopen ordering, namespace conflicts. I do believe that these
are not the issues at stake here. The real issue is about understanding
how dynamic inits do work with Xenomai, how setup descriptors can help
introducing initialization order when there was none, and progress from
there.

Whether adding support for getting parameters from envvars should be
implemented is a separate issue. Doing so would not solve every problem
regarding dynamic loading and static C++ constructors, and people
dealing with that should not put away their tin foil hat, but this can
be done elegantly, and as I said earlier, I'm not opposed to merge such
feature.

>> I understand you would like a permanent way of doing this without
>> having to provide any code.
> 
> No, but i anticipated a discussion and decided to write code when the
> outcome of the discussion is clear.
> 
>> Although I don't buy a second the argument about envvars being "more
>> standard" than command switches,
> 
> Command switches always become a problem when two or more components
> have to share the namespace. Removing your traces and not bothering

And envvars do introduce a painful issue too: submitting parameters is
not explicit anymore, and one may end up running with broken settings
from a dusted set of conflicting login / setup scripts, inheriting the
mess all way through the process hierarchy.

I do acknowledge that proper use do exist too, but let's not sell
envvars the as perfect, simple and foolproof option: with complex
systems developed and configured by many people over a long period of
time, they are not. With simple applications with only a few
user-settable parameters, they are just inconvenient compared to plain
command switches.

Besides, a real-time Xenomai application acting as a server forking
other applications is not quite the common case. the app could also
achieve that export by running setenv() on any set of parameters
received on the command line it would want to pass to the forkees. Your
point is that you would like the Xenomai libs to consider envvars
directly, which is fair enough from your standpoint, but this is
definitely not most people's requirement and as such this will never
become a default.

> the other/imposing on the other only works if the order is known. In
> Xenomai the order depends on how people link

This affirmation seems wrong when considering the way setup descriptors
are dealt with internally, actually they have been designed precisely
not to depend on the link order, and also to allow unrelated components
to initialize in proper sequence.

So I can only assume that your remark on the link order is about static
dependency vs dlopen. In that case, I still fail to see what Xenomai
libs impose which any other random library does not, when it comes to
using dlopen().

Again, could you be specific and illustrate your concern with a simple
code example that would not work with the current Xenomai implementation?

> so we can not know it for
> the general case.
> > I would not want to be the poor guy writing main() for an app where
> multiple libs think that argv is for them to use, especially with
> tricks to access it before main(). Just the fact that xenomai is
> stealing this out of /proc/self/cmdline should suggest how non-standard
> that is.
> 

I can see the rant above, but I don't get the reasoning.

First, your original mail mentioned name clashes as a reason to drop
command line options or to prefix them with --xeno, followed by a
suggestion to drop setup descriptors in favor of a generalized use of
environment variables.

If your customer's application wants to exclusively use environment
variables for its own parameters, then there is no way such variables
could conflict with any existing Xenomai command line switch.
Conversely, there is nothing in Xenomai that will prevent any piece of
application code to read the environment.

So you must be referring to the general case instead, where "some"
application - i.e. not your customer's - with requirements to use
command line switches, would clash with existing ones defined by the
Xenomai libraries.

To answer this point, I will repeat that only a handful of Xenomai
command switches have generic names (e.g. --verbose, --quiet, --silent,
--help). The rest is either prefixed, or specific enough to prevent any
confusion regarding their meaning, leaving a lot of space for variants.

So maybe the time has come to be more specific about the namespace clash
issue too: which existing Xenomai option are your referring to, which
would create a conflict with your application namespace _today_?

> Env variables are just there to look at, if you are not interested
> nobody will tell you to look at argc more of them. They survive a
> fork() if your main script needs to launch multiple xenomai apps with
> the same tuning.
> 

Reading /proc/self/cmdline is exclusively part of the auto-bootstrap
feature of a Xenomai application, and the latter is NOT required. You
can disable it at will at build time by not including the bootstrap
module in the DSO or main executable, and receive the unfiltered set of
command line switches into main() for the latter.

The auto-bootstrap is there because most applications are getting
benefit from not having to care for calling xenomai_init() explicitly,
and are just fine with receiving only the command line switches they
want to process in their main() routine, expunged from all Xenomai
switches.

The only requirement in this case would be that at some point, the
application calls xenomai_init() explicitly, before calling into Xenomai
services. If your application knows when it should dlopen() libcobalt,
it therefore knows when to call xenomai_init() too.

You could argue that enabling auto-bootstrap should not be a
default setting of the build switches returned by xeno-config,
preferring manual init of the real-time services by default, but that
is pretty much all of the extent of the issue.

>> I'm not opposed to get this kind of feature in, but only if:
>>
>> - the implementation does not reinvent the wheel of parameter parsing,
>> this would be fairly silly.
>> - the natural way of setting Xenomai parameters remains based on
>> command line switches. Most people do NOT care a dime about deferred
>> binding to libcobalt, so there is no reason to make this use case the
>> preferred one.
> 
> If we can not agree to drop at least the tunables, introducing another
> way would be insane.
>

We can't agree because this is a misconception. Tunables are entirely
orthogonal to command line switches and environment variable.
Functionally speaking, you can't replace tunables with envvars.

Each setting of a Xenomai application - whether it is defined by the
real-time libs or the user code makes no difference - can get its init
value as follows, by increasing level of precedence:

level 1- core default, this is a sane value set by the base
implementation. Usually only appropriate for simple, small apps. For
instance, the default memory pool size is 1Mb, not much for an hungry
app, but enough for most simple apps.

level 2- tunable, this is a _factory setting_ aimed at the application
developer. Quite often, only the application developer really knows how
to determine the proper value of such setting because it depends on
intimate knowledge of the innards, like the appropriate amount of memory
a given user-defined configuration would require. Such a value should be
determined by the tuning handler of a setup descriptor. Providing a
factory setting via a tunable allows you to deliver a binary executable
that will always allocate a sane amount of resources, without requiring
the end user to figure out. Unlike the core default, this one is
dynamic, it can adapt to runtime configuration bits. Whether those bits
are obtained from command line switches, envvars, config file, pigeon
post or telepathy is not relevant. At all.

level 3- command line switches, which are aimed at the end user, for
overriding any previous setting.

My proposal to automatically turn each command line defined by setup
descriptors into an implicit envvar would insert a 4th level, between
the tunable and the command line switch.

For instance, we could ask xenomai_init() to assume that since
"--mem-pool-size" was defined (in libcopperplate's setup descriptor),
there might an envvar called "XENO_MEM_POOL_SIZE" with the exact same
semantics, pulling it if present.

>> The sanest way to provide such feature would be to implicitly turn
>> every option label defined by setup descriptors into a potential
>> envvar, e.g. --cpu-affinity would be unambiguously matched by a
>> variable named "cpu_affinity". The core would look for such a
>> variable in the environment if the command line switch is not found,
>> hence giving precedence to the latter implicitly.
> 
> Yes the command line switch should still win, if they really need to
> stay. And a prefix like XENO_ should be added.
> 
>> At least, this would limit the risk of having totally unrelated ways
>> of setting core parameters, with less braindamage side-effects on
>> people with unsuitable daily amount of caffeine for the job.
>>
>> There is a way to do this properly, but this cannot be high on my todo
>> list ATM, given the ongoing work I have on my plate. Anyway, issue
>> logged.
> 
> Would you be willing to review/consider a patch that replaces the
> tuneables with env vars?
> 
No, for the reason mentioned above. However I would consider a patch
that implicitly turns options obtained from registered setup descriptors
into envvars, with lower precedence than the former, so that command
switches can always override tunables and envvars.

This said, I doubt this would fix the issue with your customer's
application: as you described it, that one is not about command line vs
envvar, this is about dealing in an orderly manner with the uncertain
combination of lazy code binding and C++ runtime mechanisms.

-- 
Philippe.

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

[Henning Schild]

Am Tue, 29 Aug 2017 13:05:47 +0200
schrieb Philippe Gerum <rpm@xenomai.org>:

> On 08/25/2017 07:16 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.
> >>
> >>  and the second one  
> >>> does not sound very nice. And for the second one i am not sure
> >>> there is always a time window in the face of static ctors
> >>> launching threads and dlopening.    
> >>
> >> That is not an issue if Xenomai setup descriptors are used
> >> properly. The "tuning" phase which may override parameters always
> >> precedes the "init" phase which considers them when allocating and
> >> bootstrapping the resources.
> >>
> >> Practically: say you have plugin.so, explicitly set dependent on
> >> libcobalt.so at link time, you will nevertheless have all ->tune()
> >> handlers run first, before the first ->init() handler is invoked.
> >> And this will happen only when xenomai_init() is called; all
> >> despite the fact that solibs are initialized in reverse dependency
> >> order (i.e. from the least dependent lib to the most dependent
> >> one).
> >>
> >> So, the way that should work with your app would be to load a proxy
> >> solib which was made dependent on libcobalt.so at build time. That
> >> proxy shared lib would define a setup descriptor, whose ->tune()
> >> handler could pull values from the environment for setting whatever
> >> runtime/config Xenomai tunable that one sees fit. That process is
> >> guaranteed to happen _before_ the Xenomai core is initialized. The
> >> proxy solib would include a Xenomai bootstrap module, calling
> >> xenomai_init().
> >>
> >> The entire process would then look like:
> >>
> >> - main() entered
> >> -- application parses argv[], no Xenomai arg in the way
> >> ...
> >> -- dlopen(plugin.so)
> >> --- libcobalt.so dependency is loaded, all setup descriptors
> >> registered --- libplugin.so is loaded, setup descriptor registered
> >> --- libplugin's bootstrap module calls xenomai_init_dso()
> >> ---- plugin->tune() is called, pulls args from the environment
> >> ---- Xenomai ->init() handlers run (using arg settings)
> >> -- back to main()
> >>
> >> With all Xenomai base parameters exclusively pulled from the
> >> environment, you could omit any Xenomai-specific option switch from
> >> the command line when spawning the app, reserving the entire option
> >> namespace to the application.
> >>
> >> I have demoed this in the attached code (the proxy lib is
> >> implemented by plugin.c). The demo code only retrieves the
> >> verbosity_level parameter from the environment, which is normally
> >> affected by --silent, --quiet and --verbose command line options,
> >> but you get the idea.  
> > 
> > I only just really looked at the example, after i asked my customer
> > to look at your response. And they kept telling me that it will not
> > work.  
> 
> This sounds like nobody tried it actually.
> 
> > 
> > Now i gave them a similar example a few months ago. Put the tuning
> > in the lib init and you are done ...
> > 
> > As far as i understand the situation:
> > We are talking about more than one "plugin" that pulls in libcobalt.
> > And the dlopens are not in main but in static ctors before main, so
> > our plugin load order is "unknown/random". So the tuning would have
> > to go into all plugins or we will need to find a way to have a
> > defined "first plugin".
> >   
> 
> This explanation is very confusing. Unlike dlmopen(), dlopen()ing
> multiple times the same shared object (and likewise its dependencies)
> only creates a single mapping at the initial opening, and only runs
> the library constructors once at that moment. This would include the
> call to xenomai_init() if the bootstrap module is present in the DSO.
>
> You could dlopen() libplugin.so directly or indirectly via the
> dependency list a hundred times, you would only get a single bootstrap
> if the bootstrap module is glued to the DSO. If not, then calling
> xenomai_init() multiple times from your app would simply lead to nop
> after the first call (with Xenomai 3.0.5).

Yes but we are not talking about the same shared object, but multiple.
Not loading libplugin.so 10 times but loading libplugin(0-9).so

So i need to find a way to load one plugin first and put the setup
descriptor in there, or i need to have the setup descriptor in every
plugin and keep them all in sync.

But enough about that example.

> > I guess we can invent libtune.so and LD_PRELOAD it. Or put that as
> > proxy into all plugins.  ... and all that vs "export XENO_foo"
> >   
> 
> I guess that your customer may want to clearly explain what they want
> to achieve by sketching their init process and the software
> components in the picture, because at this point, I could not figure
> out what their problem is. I'm not keen on continuing this discussion
> only based on guesses.
> 
> On a general note, I believe that this discussion took the wrong track
> by mentioning orthogonal and often unrelated issues such as
> constructor priority, dlopen ordering, namespace conflicts. I do
> believe that these are not the issues at stake here. The real issue
> is about understanding how dynamic inits do work with Xenomai, how
> setup descriptors can help introducing initialization order when
> there was none, and progress from there.
> 
> Whether adding support for getting parameters from envvars should be
> implemented is a separate issue. Doing so would not solve every
> problem regarding dynamic loading and static C++ constructors, and
> people dealing with that should not put away their tin foil hat, but
> this can be done elegantly, and as I said earlier, I'm not opposed to
> merge such feature.
> 
> >> I understand you would like a permanent way of doing this without
> >> having to provide any code.  
> > 
> > No, but i anticipated a discussion and decided to write code when
> > the outcome of the discussion is clear.
> >   
> >> Although I don't buy a second the argument about envvars being
> >> "more standard" than command switches,  
> > 
> > Command switches always become a problem when two or more components
> > have to share the namespace. Removing your traces and not
> > bothering  
> 
> And envvars do introduce a painful issue too: submitting parameters is
> not explicit anymore, and one may end up running with broken settings
> from a dusted set of conflicting login / setup scripts, inheriting the
> mess all way through the process hierarchy.
> 
> I do acknowledge that proper use do exist too, but let's not sell
> envvars the as perfect, simple and foolproof option: with complex
> systems developed and configured by many people over a long period of
> time, they are not. With simple applications with only a few
> user-settable parameters, they are just inconvenient compared to plain
> command switches.
> 
> Besides, a real-time Xenomai application acting as a server forking
> other applications is not quite the common case. the app could also
> achieve that export by running setenv() on any set of parameters
> received on the command line it would want to pass to the forkees.
> Your point is that you would like the Xenomai libs to consider envvars
> directly, which is fair enough from your standpoint, but this is
> definitely not most people's requirement and as such this will never
> become a default.
> 
> > the other/imposing on the other only works if the order is known. In
> > Xenomai the order depends on how people link  
>
> This affirmation seems wrong when considering the way setup
> descriptors are dealt with internally, actually they have been
> designed precisely not to depend on the link order, and also to allow
> unrelated components to initialize in proper sequence.
> 
> So I can only assume that your remark on the link order is about
> static dependency vs dlopen. In that case, I still fail to see what
> Xenomai libs impose which any other random library does not, when it
> comes to using dlopen().

This section was about command line parameters. With ld.so xenomai_init
comes before main, with dlopen it might come before or after main. So
the order is undefined.

> Again, could you be specific and illustrate your concern with a simple
> code example that would not work with the current Xenomai
> implementation?

In the case where dlopen comes after main, main needs to be modified to
ignore args for xenomai, or args can not be used.
And "void usage()" needs to be modified to print xenomai --help as well
before exiting.

> > so we can not know it for
> > the general case.  
> > > I would not want to be the poor guy writing main() for an app
> > > where  
> > multiple libs think that argv is for them to use, especially with
> > tricks to access it before main(). Just the fact that xenomai is
> > stealing this out of /proc/self/cmdline should suggest how
> > non-standard that is.
> >   
> 
> I can see the rant above, but I don't get the reasoning.
> 
> First, your original mail mentioned name clashes as a reason to drop
> command line options or to prefix them with --xeno, followed by a
> suggestion to drop setup descriptors in favor of a generalized use of
> environment variables.

That is the case where dlopen comes after main and main needs to ignore
the args you want to pass to xenomai. There has been not been any
filtering out yet, the application will have to do it. 
 
> If your customer's application wants to exclusively use environment
> variables for its own parameters, then there is no way such variables
> could conflict with any existing Xenomai command line switch.
> Conversely, there is nothing in Xenomai that will prevent any piece of
> application code to read the environment.
> 
> So you must be referring to the general case instead, where "some"
> application - i.e. not your customer's - with requirements to use
> command line switches, would clash with existing ones defined by the
> Xenomai libraries.
> 
> To answer this point, I will repeat that only a handful of Xenomai
> command switches have generic names (e.g. --verbose, --quiet,
> --silent, --help). The rest is either prefixed, or specific enough to
> prevent any confusion regarding their meaning, leaving a lot of space
> for variants.
> 
> So maybe the time has come to be more specific about the namespace
> clash issue too: which existing Xenomai option are your referring to,
> which would create a conflict with your application namespace _today_?

'--help' in dlopen() vs. static/dynamic

> > Env variables are just there to look at, if you are not interested
> > nobody will tell you to look at argc more of them. They survive a
> > fork() if your main script needs to launch multiple xenomai apps
> > with the same tuning.
> >   
> 
> Reading /proc/self/cmdline is exclusively part of the auto-bootstrap
> feature of a Xenomai application, and the latter is NOT required. You
> can disable it at will at build time by not including the bootstrap
> module in the DSO or main executable, and receive the unfiltered set
> of command line switches into main() for the latter.
> 
> The auto-bootstrap is there because most applications are getting
> benefit from not having to care for calling xenomai_init() explicitly,
> and are just fine with receiving only the command line switches they
> want to process in their main() routine, expunged from all Xenomai
> switches.

The problem was never xenomai removing args from argv before main can
see them.

> The only requirement in this case would be that at some point, the
> application calls xenomai_init() explicitly, before calling into
> Xenomai services. If your application knows when it should dlopen()
> libcobalt, it therefore knows when to call xenomai_init() too.
> 
> You could argue that enabling auto-bootstrap should not be a
> default setting of the build switches returned by xeno-config,
> preferring manual init of the real-time services by default, but that
> is pretty much all of the extent of the issue.
> 
> >> I'm not opposed to get this kind of feature in, but only if:
> >>
> >> - the implementation does not reinvent the wheel of parameter
> >> parsing, this would be fairly silly.
> >> - the natural way of setting Xenomai parameters remains based on
> >> command line switches. Most people do NOT care a dime about
> >> deferred binding to libcobalt, so there is no reason to make this
> >> use case the preferred one.  
> > 
> > If we can not agree to drop at least the tunables, introducing
> > another way would be insane.
> >  
> 
> We can't agree because this is a misconception. Tunables are entirely
> orthogonal to command line switches and environment variable.
> Functionally speaking, you can't replace tunables with envvars.
> 
> Each setting of a Xenomai application - whether it is defined by the
> real-time libs or the user code makes no difference - can get its init
> value as follows, by increasing level of precedence:
> 
> level 1- core default, this is a sane value set by the base
> implementation. Usually only appropriate for simple, small apps. For
> instance, the default memory pool size is 1Mb, not much for an hungry
> app, but enough for most simple apps.
> 
> level 2- tunable, this is a _factory setting_ aimed at the application
> developer. Quite often, only the application developer really knows
> how to determine the proper value of such setting because it depends
> on intimate knowledge of the innards, like the appropriate amount of
> memory a given user-defined configuration would require. Such a value
> should be determined by the tuning handler of a setup descriptor.
> Providing a factory setting via a tunable allows you to deliver a
> binary executable that will always allocate a sane amount of
> resources, without requiring the end user to figure out. Unlike the
> core default, this one is dynamic, it can adapt to runtime
> configuration bits. Whether those bits are obtained from command line
> switches, envvars, config file, pigeon post or telepathy is not
> relevant. At all.
> 
> level 3- command line switches, which are aimed at the end user, for
> overriding any previous setting.
> 
> My proposal to automatically turn each command line defined by setup
> descriptors into an implicit envvar would insert a 4th level, between
> the tunable and the command line switch.
>
> For instance, we could ask xenomai_init() to assume that since
> "--mem-pool-size" was defined (in libcopperplate's setup descriptor),
> there might an envvar called "XENO_MEM_POOL_SIZE" with the exact same
> semantics, pulling it if present.

We already have 3 layers adding another one is imho not a good idea.
People will have to understand the precedence.

Again it would be nice if there was just one way to change the values,
resulting in 2 levels.

These are the problems we so far discovered in the two ways we have
today

level 2:
 - tuning only works for the first guy to call xenomai_init
   - tuning in the second and n-th lib will fail silently, due to
     implementation, not general mechanism
 - users need a deep understanding of the linking process and make sure
   they always know/control who will be the first
   - many dlopen()s or many .so s in ldd
level 3:
 - does not play well with dlopen(), see above
 
> >> The sanest way to provide such feature would be to implicitly turn
> >> every option label defined by setup descriptors into a potential
> >> envvar, e.g. --cpu-affinity would be unambiguously matched by a
> >> variable named "cpu_affinity". The core would look for such a
> >> variable in the environment if the command line switch is not
> >> found, hence giving precedence to the latter implicitly.  
> > 
> > Yes the command line switch should still win, if they really need to
> > stay. And a prefix like XENO_ should be added.
> >   
> >> At least, this would limit the risk of having totally unrelated
> >> ways of setting core parameters, with less braindamage
> >> side-effects on people with unsuitable daily amount of caffeine
> >> for the job.
> >>
> >> There is a way to do this properly, but this cannot be high on my
> >> todo list ATM, given the ongoing work I have on my plate. Anyway,
> >> issue logged.  
> > 
> > Would you be willing to review/consider a patch that replaces the
> > tuneables with env vars?
> >   
> No, for the reason mentioned above. However I would consider a patch
> that implicitly turns options obtained from registered setup
> descriptors into envvars, with lower precedence than the former, so
> that command switches can always override tunables and envvars.

I doubt we need yet another mechanism and layer it is complex enough as
it is today.

Henning

> This said, I doubt this would fix the issue with your customer's
> application: as you described it, that one is not about command line
> vs envvar, this is about dealing in an orderly manner with the
> uncertain combination of lazy code binding and C++ runtime mechanisms.
> 

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

[Philippe Gerum]

On 08/29/2017 02:27 PM, Henning Schild wrote:
> Am Tue, 29 Aug 2017 13:05:47 +0200
> schrieb Philippe Gerum <rpm@xenomai.org>:

>> You could dlopen() libplugin.so directly or indirectly via the
>> dependency list a hundred times, you would only get a single bootstrap
>> if the bootstrap module is glued to the DSO. If not, then calling
>> xenomai_init() multiple times from your app would simply lead to nop
>> after the first call (with Xenomai 3.0.5).
> 
> Yes but we are not talking about the same shared object, but multiple.
> Not loading libplugin.so 10 times but loading libplugin(0-9).so
> 
> So i need to find a way to load one plugin first and put the setup
> descriptor in there, or i need to have the setup descriptor in every
> plugin and keep them all in sync.
> 

You don't have to do either, because you don't have multiple
libplugin.so the way I see it. You have multiple application DSOs you
want to dlopen() directly, all depending on a single libplugin.so, which
eventually depends on libcobalt.so.

libplugin.so is a misnomer actually, I should have called it
libcobalt-setup.so, because it only does that: i.e. tuning the Xenomai
core with settings pulled from the environment before xenomai_init_dso()
starts the former. And the latter is contained in the bootstrap module
which should be glued to libcobalt-setup.so via the auto-init-solib
mechanism.

To sum up, say you have two application DSOs, namely libfoo.so and
libbar.so, all depending on Xenomai for getting real-time services. The
chain of dependency should then be:

dlopen("libfoo.so")
          \
           > libcobalt-setup.so -> libcobalt.so
          /
dlopen("libbar.so")

libfoo.so and libbar.so should have been made dependent on
libcobalt-setup.so at build time.

At the end of the day, dlopen() ensured that libcobalt-setup.so and
libcobalt.so have been mapped only once, with their respective library
constructors executed only once. Since setup descriptors are registered
by those constructors, the unique instance of your setup descriptor has
been registered once, ready to be activated by xenomai_init_dso() -
which happens last.

Calling dlopen() from static C++ constructors does not change the
situation, it does work just like illustrated without any unexpected
trap. I have just verified it locally.

>>
>> First, your original mail mentioned name clashes as a reason to drop
>> command line options or to prefix them with --xeno, followed by a
>> suggestion to drop setup descriptors in favor of a generalized use of
>> environment variables.
> 
> That is the case where dlopen comes after main and main needs to ignore
> the args you want to pass to xenomai. There has been not been any
> filtering out yet, the application will have to do it. 
>  

Have we been talking about heavily refactoring the Xenomai setup
mechanism only because the code below would be deemed complex, ugly and
non-standard according to your customer? If so, I disagree.

#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>
#include <xenomai/init.h>

static const struct option options[] = {
	{
#define help_opt	0
		.name = "help",
	},
	{
#define parm_opt	1
		.name = "parm",
		.has_arg = required_argument,
	},
	{ /* sentinel. */ }
};

int main(int argc, char *argv[])
{
	int c, lindex;

	opterr = 0;
	for (;;) {
		lindex = -1;
		c = getopt_long(argc, argv, "", options, &lindex);
		if (c == EOF)
			break;
		if (lindex == -1) { /* c == '?' */
			printf("discarding somebody else's option\n");
			continue;
		}

		printf("found application option '%s'\n", options[lindex]);

		switch (lindex) {
		case help_opt:
			application_usage();
			xenomai_usage();
			exit(0);
		case parm_opt:
			apply_application_setting(optarg);
			break;
		}
	}
	
	return 0;
}

> We already have 3 layers adding another one is imho not a good idea.
> People will have to understand the precedence.
>

That won't fly. tunables are the only sane way for application
developers to define sensible built-in factory settings in Xenomai
applications, which is aware of the boot order of software components.
Dropping them would be a net loss in the field.
> Again it would be nice if there was just one way to change the values,
> resulting in 2 levels.
> 
> These are the problems we so far discovered in the two ways we have
> today
> 
> level 2:
>  - tuning only works for the first guy to call xenomai_init
>    - tuning in the second and n-th lib will fail silently, due to
>      implementation, not general mechanism
>  - users need a deep understanding of the linking process and make sure
>    they always know/control who will be the first
>    - many dlopen()s or many .so s in ldd

There is no reason to tune the system multiple times based on the same
set of settings, for initializing the same machinery. I believe that you
only need and want a single setup descriptor in your dependency chain
down to libcobalt.so. There is no requirement for knowing the link order
either.

> level 3:
>  - does not play well with dlopen(), see above
>

The only aspect that depends on static vs dlopen is who is going to
process the argument vector first, and there are fairly simple solutions
for both ways.

> I doubt we need yet another mechanism and layer it is complex enough as
> it is today.
> 

We may agree to disagree on this. Tunables won't go away, but we can
provide a simple mechanism for removing the need to populate the command
line with Xenomai arguments, if using getopt() is really a burden for
your customer.

-- 
Philippe.

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

[Henning Schild]

Am Tue, 29 Aug 2017 18:10:12 +0200
schrieb Philippe Gerum <rpm@xenomai.org>:

> On 08/29/2017 02:27 PM, Henning Schild wrote:
> > Am Tue, 29 Aug 2017 13:05:47 +0200
> > schrieb Philippe Gerum <rpm@xenomai.org>:  
> 
> >> You could dlopen() libplugin.so directly or indirectly via the
> >> dependency list a hundred times, you would only get a single
> >> bootstrap if the bootstrap module is glued to the DSO. If not,
> >> then calling xenomai_init() multiple times from your app would
> >> simply lead to nop after the first call (with Xenomai 3.0.5).  
> > 
> > Yes but we are not talking about the same shared object, but
> > multiple. Not loading libplugin.so 10 times but loading
> > libplugin(0-9).so
> > 
> > So i need to find a way to load one plugin first and put the setup
> > descriptor in there, or i need to have the setup descriptor in every
> > plugin and keep them all in sync.
> >   
> 
> You don't have to do either, because you don't have multiple
> libplugin.so the way I see it. You have multiple application DSOs you
> want to dlopen() directly, all depending on a single libplugin.so,
> which eventually depends on libcobalt.so.
> 
> libplugin.so is a misnomer actually, I should have called it
> libcobalt-setup.so, because it only does that: i.e. tuning the Xenomai
> core with settings pulled from the environment before
> xenomai_init_dso() starts the former. And the latter is contained in
> the bootstrap module which should be glued to libcobalt-setup.so via
> the auto-init-solib mechanism.
> 
> To sum up, say you have two application DSOs, namely libfoo.so and
> libbar.so, all depending on Xenomai for getting real-time services.
> The chain of dependency should then be:
> 
> dlopen("libfoo.so")
>           \
>            > libcobalt-setup.so -> libcobalt.so  
>           /
> dlopen("libbar.so")
> 
> libfoo.so and libbar.so should have been made dependent on
> libcobalt-setup.so at build time.
> 
> At the end of the day, dlopen() ensured that libcobalt-setup.so and
> libcobalt.so have been mapped only once, with their respective library
> constructors executed only once. Since setup descriptors are
> registered by those constructors, the unique instance of your setup
> descriptor has been registered once, ready to be activated by
> xenomai_init_dso() - which happens last.
> 
> Calling dlopen() from static C++ constructors does not change the
> situation, it does work just like illustrated without any unexpected
> trap. I have just verified it locally.

I understood all of that and referred to that guy as libtune that i
would need to LD_PRELOAD or smuggle into the chain. Problem solved, no
need to continue that discussion.

> >>
> >> First, your original mail mentioned name clashes as a reason to
> >> drop command line options or to prefix them with --xeno, followed
> >> by a suggestion to drop setup descriptors in favor of a
> >> generalized use of environment variables.  
> > 
> > That is the case where dlopen comes after main and main needs to
> > ignore the args you want to pass to xenomai. There has been not
> > been any filtering out yet, the application will have to do it. 
> >    
> 
> Have we been talking about heavily refactoring the Xenomai setup
> mechanism only because the code below would be deemed complex, ugly
> and non-standard according to your customer? If so, I disagree.
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <getopt.h>
> #include <xenomai/init.h>
> 
> static const struct option options[] = {
> 	{
> #define help_opt	0
> 		.name = "help",
> 	},
> 	{
> #define parm_opt	1
> 		.name = "parm",
> 		.has_arg = required_argument,
> 	},
> 	{ /* sentinel. */ }
> };
> 
> int main(int argc, char *argv[])
> {
> 	int c, lindex;
> 
> 	opterr = 0;
> 	for (;;) {
> 		lindex = -1;
> 		c = getopt_long(argc, argv, "", options, &lindex);
> 		if (c == EOF)
> 			break;
> 		if (lindex == -1) { /* c == '?' */
> 			printf("discarding somebody else's option\n");
> 			continue;
> 		}
> 
> 		printf("found application option '%s'\n",
> options[lindex]);
> 
> 		switch (lindex) {
> 		case help_opt:
> 			application_usage();

dlopen() ...

> 			xenomai_usage();
> 			exit(0);
> 		case parm_opt:
> 			apply_application_setting(optarg);
> 			break;
> 		}
> 	}
> 	
> 	return 0;
> }

app --mem-SiZe-P00l=4M --hepl
 "discarding somebody else's option\n"^2
 -ENOMEM
 
> > We already have 3 layers adding another one is imho not a good idea.
> > People will have to understand the precedence.
> >  
> 
> That won't fly. tunables are the only sane way for application
> developers to define sensible built-in factory settings in Xenomai
> applications, which is aware of the boot order of software components.
> Dropping them would be a net loss in the field.
> > Again it would be nice if there was just one way to change the
> > values, resulting in 2 levels.
> > 
> > These are the problems we so far discovered in the two ways we have
> > today
> > 
> > level 2:
> >  - tuning only works for the first guy to call xenomai_init
> >    - tuning in the second and n-th lib will fail silently, due to
> >      implementation, not general mechanism
> >  - users need a deep understanding of the linking process and make
> > sure they always know/control who will be the first
> >    - many dlopen()s or many .so s in ldd  
> 
> There is no reason to tune the system multiple times based on the same
> set of settings, for initializing the same machinery. I believe that
> you only need and want a single setup descriptor in your dependency
> chain down to libcobalt.so. There is no requirement for knowing the
> link order either.

That is all true as long as you assume that the application code base
is any cleaner than the mess of old envvars you talked about earlier.
In reality people will fiddle in setup descriptors all over the place,
just like they set env-variables in funny places.

> > level 3:
> >  - does not play well with dlopen(), see above
> >  
> 
> The only aspect that depends on static vs dlopen is who is going to
> process the argument vector first, and there are fairly simple
> solutions for both ways.

I still did not understand how i can ignore xenomai args without
risking ignoring basically everything or keeping a list of xenomai
args in my app. In the case where dlopen comes after main.

> > I doubt we need yet another mechanism and layer it is complex
> > enough as it is today.
> >   
> 
> We may agree to disagree on this. Tunables won't go away, but we can
> provide a simple mechanism for removing the need to populate the
> command line with Xenomai arguments, if using getopt() is really a
> burden for your customer.

Yes let us agree to disagree and not change anything in Xenomai.

I do not mind changing the customers software to address the issue
there. The whole thread was about making xenomai simpler, inspired by
having to look deeper into the settings/tuneables.
The fact that we had to talk about it for so long could indicate that
the whole thing is not so simple.

Henning

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

[Philippe Gerum]

On 08/29/2017 07:20 PM, Henning Schild wrote:
> I do not mind changing the customers software to address the issue
> there. The whole thread was about making xenomai simpler, inspired by
> having to look deeper into the settings/tuneables.
> The fact that we had to talk about it for so long could indicate that
> the whole thing is not so simple.
> 

Don't you want to get a stab at the proposal to turn all Xenomai
parameters found in setup descriptors to potential/possible environment
variables?

I believe that this would fit your bill, without causing any regression
to other existing applications that may already depend on the tuning
mechanism. That seems to be a fair deal to me.

-- 
Philippe.

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

[Philippe Gerum]

On 08/29/2017 10:02 PM, Philippe Gerum wrote:
> On 08/29/2017 07:20 PM, Henning Schild wrote:
>> I do not mind changing the customers software to address the issue
>> there. The whole thread was about making xenomai simpler, inspired by
>> having to look deeper into the settings/tuneables.
>> The fact that we had to talk about it for so long could indicate that
>> the whole thing is not so simple.
>>
> 
> Don't you want to get a stab at the proposal to turn all Xenomai
> parameters found in setup descriptors to potential/possible environment
> variables?
> 
> I believe that this would fit your bill, without causing any regression
> to other existing applications that may already depend on the tuning
> mechanism. That seems to be a fair deal to me.
> 

For the sake of clarity, I'm referring to introducing an automatic
probing rule that says:

"if switch --foo exists, then maybe envvar XENO_FOO exists as well, and
if so, let's preload the value of the foo parameter with it, leaving
precedence to --foo eventually".

$ XENO_FOO=2 ./app
receives foo=2

$ XENO_FOO=2 ./app --foo 3
receives foo=3

./app --foo 4
receives foo=4

./app
receives default core value set by Xenomai libs, or the factory setting
defined by the application code.

-- 
Philippe.

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

[Henning Schild]

Am Tue, 29 Aug 2017 22:02:06 +0200
schrieb Philippe Gerum <rpm@xenomai.org>:

> On 08/29/2017 07:20 PM, Henning Schild wrote:
> > I do not mind changing the customers software to address the issue
> > there. The whole thread was about making xenomai simpler, inspired
> > by having to look deeper into the settings/tuneables.
> > The fact that we had to talk about it for so long could indicate
> > that the whole thing is not so simple.
> >   
> 
> Don't you want to get a stab at the proposal to turn all Xenomai
> parameters found in setup descriptors to potential/possible
> environment variables?

No. I would like to replace one or both of the existing mechanisms with
envvars (or something else ...). Introducing another one would make it
even more complicated. The replaced mechanisms should be deprecated and
eventually removed.

> I believe that this would fit your bill, without causing any
> regression to other existing applications that may already depend on
> the tuning mechanism. That seems to be a fair deal to me.

Sure, but i am not comfortable with increasing complexity further.

Henning

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

[Stéphane Ancelot]

Hi,

hardcoded and cmdline args benefits from an added value for real 
applications. We don't want args being "volatile"

environment variables are volatile and sometimes difficult to propagate 
between shells...

Regards,

S.Ancelot


Le 08/08/2017 à 11:23, Henning Schild a écrit :
> Hey,
>
> xenomai3 has its tuneables and they can be set with command-line
> parameters and setup_descriptors.
>
> 1.
> The command-line parameters impose on the application, it has to be
> modified to skip/ignore them. And ultimately it has to keep a list of
> valid ones to do so pedanticly. If there are name clashes behaviour is
> unclear. i.e. "--help" ld.so vs. dlopen
>
> 2.
> The setup_descriptors do work but they rely on getting the order
> stricly right. They have to execute before the first xenomai_init(). In
> complex applications with multithreaded init using dlopen() and
> auto-init-solib that quickly turns out to be unusable.
>
> Suggestions:
> 1.
> 1.1 completely drop the support for parameters and the fiddling
>      with /proc/cmdline
> 1.2 or agree on a prefix "--xeno-" so the application can ignore all
>      xenomai parameters without knowing all
>
> 2.
> 2.1 completely drop the setup_descriptors in favour of environment
>      variables
>
> That would be a drastic change but i think we should do something about
> it. With environment variables it is clear what happens without messing
> with the applications init or parameters, getting rid of confusing
> complexity.
>
> Please let me know what you think, i would be happy to prepare patches.
>
> Henning
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

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

[Jan Kiszka]

On 2017-08-28 08:25, Stéphane Ancelot wrote:
> Hi,
> 
> hardcoded and cmdline args benefits from an added value for real
> applications. We don't want args being "volatile"
> 
> environment variables are volatile and sometimes difficult to propagate
> between shells...

This is not about removing command line options completely. You can
still choose them if they fit your case better.

But given all the problems they cause to complex programs due to their
invasive nature, let's just make them them opt-in in 3.1 and switch to
conceptually cleaner env vars by default. For stable 3.0, we would keep
command line options as default, of course.

Jan