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 _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
