> -----Original Message-----
> From: Jan Kiszka <jan.kis...@siemens.com>
> Sent: Dienstag, 4. Dezember 2018 18:59
> To: Lange Norbert <norbert.la...@andritz.com>
> Cc: Xenomai <xenomai@xenomai.org>; Philippe Gerum
> <r...@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
> ATTACHMENTS.
>
>
> On 04.12.18 18:21, Lange Norbert wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jan Kiszka <jan.kis...@siemens.com>
> >> Sent: Dienstag, 4. Dezember 2018 17:30
> >> To: Lange Norbert <norbert.la...@andritz.com>
> >> Cc: Xenomai <xenomai@xenomai.org>; Philippe Gerum
> <r...@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
> ATTACHMENTS.
> >>
> >>
> >> 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)
{
#ifdef _XENOMAI_BOOTSTRAP_DSO
xenomai_init_dso(...);
#else
xenomai_init(....);
#endif
}
__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
> (lib/boilerplate/init/bootstrap.c)
> > 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
Norbert
________________________________
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
DVR: 0605077
UID-Nr.: ATU14756806
Thank You
________________________________
