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

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