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