On 08/21/2017 01:12 PM, Henning Schild wrote: > Am Wed, 16 Aug 2017 20:13:34 +0200 > schrieb Philippe Gerum <[email protected]>: > >> 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. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
