improve and provide a header for bootstrapping

Jan Kiszka jan.kiszka at
Tue Dec 4 18:59:05 CET 2018

On 04.12.18 18:21, Lange Norbert wrote:
>> -----Original Message-----
>> From: Jan Kiszka <jan.kiszka at>
>> Sent: Dienstag, 4. Dezember 2018 17:30
>> To: Lange Norbert <norbert.lange at>
>> Cc: Xenomai <xenomai at>; Philippe Gerum
>> <rpm at>
>> Subject: Re: improve and provide a header for bootstrapping
>> On 04.12.18 16:53, Lange Norbert wrote:
>>> So any update on this.
>>> Do you have something similar to patchwork to keep up on those loose
>> email-threads?
>> This was less a patch tracking issue than the missing decision how to address
>> the topic.
> I understand that, but there is still a lack of feedback. (And I already brought that topic
> up some months ago, so there is some redundancy explaining it again).

Just saw your first round from April which didn't get any feedback at all - not 
optimal, I agree.

>> On the one hand, I see a desire to control bootstrapping in more details. On
>> the other hand, I wonder how much *additional* control is practically
>> needed - did you study --no-auto-init sufficiently? And I wonder how much
>> new interfaces we want to open up that way.
> Yes I know --no-auto-init, but that’s only one side of the story. What are you doing
> in place of auto-init?

Call xenomai_init() - or what are you missing then?

> To me, the most sensible approach is to place building blocks in the xenomai
> Headers and libraries.
> *   parsing of the commandline args got moved from the bootstrap (lib/boilerplate/init/bootstrap.c)
>      to the DSO. Don’t want to replicate this everywhere

Are you using command line parameters to tune the Xenomai core?

> *   the setup code from bootstrapping is separated from the main wrapping magic (currently this is either both or none)
>      That’s currently done with a header, as quite frankly proving object code does not scale well with compilerflags and options.
> What I generally want is to easily add the setup code into an application, while avoiding the additional wrapping magic.
> The cause of action is either to do everything myself or try to modulize the upstream bootstrapping.
> In terms of external interfaces, only 'xenomai_init_fetchargv' would be added to libcobalt/libmercury.
> A second function 'xenomai_bootstrap_getargv' is defined by the bootstrapping code,
> to be consumed by the application (or can be ignored).

In fact, the other reason I'm reluctant to create new interfaces here is that I 
don't believe hooking into the command line of the main process is a good 
interface for a library like Xenomai in the first place. We had problems with 
that before, and I would rather like to think about moving away from it. Without 
all that parameter parsing, xenomai_init would take void as arguments, and we 
had no need for moving code around here.

A better interface for Xenomai would actually be prefixed (e.g. "XENO_") 
environment variables, because they do not interfere with the process' command 
line and can be picked up or even modified without much effort at any point 
between application start and xenomai initialization.


Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

More information about the Xenomai mailing list