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.
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.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
