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.
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.
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.
Jan
-----Original Message-----
From: Xenomai <xenomai-boun...@xenomai.org> On Behalf Of Norbert
Lange
Sent: Freitag, 26. Oktober 2018 18:36
To: jan.kis...@siemens.com
Cc: Xenomai <xenomai@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.
Am Fr., 26. Okt. 2018 um 15:48 Uhr schrieb Jan Kiszka
<jan.kis...@siemens.com>:
On 23.10.18 16:16, Norbert Lange wrote:
Hello,
the following patches allow a variety of options additional to the
linker magic involved for hijacking the aplications main function.
the original method will still continue to work, differences are
* the code dealing with retrieving the commandline arguments
is moved into libcobale/libmercury. Making the necessary per-
application
code much smaller.
* the implementation was moved into a header, with several macros
controlling functionality (not everyone wants to define a main
function).
The approach I use personally is to compile and link my own
bootstrap code, which is preferable in many build systems as
source-files are understood while objects files generally need some
special care. (And it cant hurt if the compiler flags match exactly).
As example:
----- add this to your file containing main
int xenomai_init_getargv(int *argc, char *const** argv);
int main(int argc, char *const argv[]) { #if defined(__COBALT__) ||
defined(__MERCURY__)
xenomai_init_getargv(&argc, &argv); #endif
....
}
----- create another file, lets call it mybootstrap.c
#define _XENOMAI_BOOTSTRAP_GLIBC_CONSTRUCTORS
#include <xenomai/bootstrap-template.h>
----------------------------------------------
Norbert
[PATCH 1/2] separate bootstrap code to get commandline, move it into
[PATCH 2/2] add a header to create flexible bootstrap code
I need to look more carefully at the details and your use case, but my
first impression is that at least patch 2 is not very beautiful due to
that large template header. Could you explain again why explicitly
calling the bootstrap code in a library is not sufficient?
Just so that we are on the same page, the bootstrap code thats generated
looks like this (in a couple variants):
----------------
#include <xenomai/init.h>
static int early_argc;
static char *const *early_argv;
int xenomai_bootstrap_getargv(int *argc, char *const** argv) { if
(early_argc) { *argc = early_argc; *argv = early_argv; return 1; } return 0; }
__bootstrap_ctor static void xenomai_bootstrap(void) { char *const *argv;
int argc; if (xenomai_init_fetchargv(&argc, &argv) != 0) return;
xenomai_init(&argc, &argv); early_argc = argc; early_argv = argv; }
----------------------
I believe what you meant with bootstrap code is called with 'xenomai_init',
and I dont plan to touch or replace that.
The code further replicates the code from lib/boilerplate/init/bootstrap.c,
with the important difference, that you can chose not to define a main
function and assorted wrappers (one of my main motivations is to
disable/separate that).
Also note that this pattern may make it harder to maintain a
compatible interface along updates, increasing the risk of having to
recompile your application, rather than just replacing some central library,
when Xenomai changes.
before Patch #2:
your-app --links-> lib/xenomai/bootstrap.o --calls->xenomai_init
after Patch #2 (and an optional variant):
your-app --contains-> include/xenomai/bootstrap-template.h
--calls->xenomai_init
this means I need no precompiled object 'lib/xenomai/bootstrap.o', and the
ABI to the libs has not changed.
You call a large header with functions not beautiful, I would call precompiled
objects and the linker wrapping not beautiful.
If we are pragmatic, with Patch #2 you can pick between 2 not beautiful
solutions =)
Patch #1 is the one changing the ABI in a not BW-compatible manner (adds
one function), but Patch #2 arguably improves on that, as the .o objects from
a compiler have no ABI stability guarantee whatsoever.
Further I can freely use no-pic/pic/pie and other ABI-changing settings, as
there is no need to link a object with potentially incompatible ABI (compiler,-
version or settings).
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
________________________________
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
