improve and provide a header for bootstrapping
norbert.lange at andritz.com
Wed Dec 5 14:23:35 CET 2018
> -----Original Message-----
> From: Jan Kiszka <jan.kiszka at siemens.com>
> Sent: Dienstag, 4. Dezember 2018 18:59
> To: Lange Norbert <norbert.lange at andritz.com>
> Cc: Xenomai <xenomai at xenomai.org>; Philippe Gerum
> <rpm at xenomai.org>
> Subject: Re: improve and provide a header for bootstrapping
> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE
> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> On 04.12.18 18:21, Lange Norbert wrote:
> >> -----Original Message-----
> >> From: Jan Kiszka <jan.kiszka at siemens.com>
> >> Sent: Dienstag, 4. Dezember 2018 17:30
> >> To: Lange Norbert <norbert.lange at andritz.com>
> >> Cc: Xenomai <xenomai at xenomai.org>; Philippe Gerum
> <rpm at xenomai.org>
> >> Subject: Re: improve and provide a header for bootstrapping
> >> E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE,
> >> EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR
> >> 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.
Some public issue tracker would be badly needed IMHO
> >> 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?
Call it when from where? If its called manually from main, then you must not use xenomai from "constructor" functions (global C++ object initializers). And its slightly different for DSOs.
What I would want is a template for this, like aa minimum:
__bootstrap_ctor static void xenomai_bootstrap(void)
__bootstrap_ctor, xenomai_init_dso, xenomai_init all are interface details,
that would fit best in an upstream header.
> > 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
> > to the DSO. Don’t want to replicate this everywhere
> Are you using command line paramete - main funtionrs to tune the Xenomai core?
No, and *I* don’t want to. The larger context is https://github.com/nolange/cmake_xenomai/tree/master/patchset,
I would want to have CMake support, which should include the existing usecases.
The aim would be to have CMake automatically use the right bootstrap method,
And be agnostic to compiler settings (means I would want to compile the boostrap code
identical to the rest of the application).
> > * 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.
How about backwards compatibility (otherwise I agree)?
I was trying to stay 100% compatible with the old approach
while allowing modifications.
> 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.
Env variables are kinda invisible for the user though, and I would not want to tweak parameters
(or be able to) outside of development.
What about ripping out every automatism and make this explicit? Ie.
xenomai_init taking an array of tuneable parameters.
The app can then decide where it fetches those parameter from,
Some (MIT-licensed) template functions could be available in Xenomai.
That way you don’t add any technological debt to the interface.
(I would prefer these to be installed as source, and compiled with applications.)
A nice solution would be libraries you can LD_PRELOAD, which intercept
The xenomai_init call to add parameters
This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.
ANDRITZ HYDRO GmbH
Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
Firmensitz/ Registered seat: Wien
Firmenbuchgericht/ Court of registry: Handelsgericht Wien
Firmenbuchnummer/ Company registration: FN 61833 g
More information about the Xenomai