improve and provide a header for bootstrapping

Lange Norbert norbert.lange at andritz.com
Tue Dec 4 18:21:06 CET 2018



> -----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, 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).

> 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?
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
*   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).

>
> Providing a user interface based on larger code templates does not make me
> feel comfortable at all. That's why I'm reluctant to move into that direction.
>
> Philippe is busy these days, but maybe later he - as the original designer of
> this code - can comment on the envisioned use cases and potential
> limitations.

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
________________________________


More information about the Xenomai mailing list