On 08/08/2017 11:23 AM, Henning Schild wrote:

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

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.

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.

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.1 completely drop the setup_descriptors in favour of environment

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

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.


Xenomai mailing list

Reply via email to