All of lore.kernel.org
 help / color / mirror / Atom feed
From: Henning Schild <henning.schild@siemens.com>
To: Philippe Gerum <rpm@xenomai.org>
Cc: "KISZKA, JAN" <jan.kiszka@siemens.com>, xenomai@xenomai.org
Subject: Re: [Xenomai] [RFC] Xenomai3 tuneables replaced by environment variables
Date: Tue, 8 Aug 2017 13:48:01 +0200	[thread overview]
Message-ID: <20170808134801.59ae5de6@md1em3qc> (raw)
In-Reply-To: <a676257d-9e88-1b81-15e6-adfffc1c7716@xenomai.org>

Am Tue, 8 Aug 2017 12:24:54 +0200
schrieb Philippe Gerum <rpm@xenomai.org>:

> On 08/08/2017 11:23 AM, Henning Schild wrote:
> > Hey,
> >
> > xenomai3 has its tuneables and they can be set with command-line
> > parameters and setup_descriptors.
> >
> > 1.
> > The command-line parameters impose on the application, it has to be
> > modified to skip/ignore them.  
> 
> No, the core takes care of this. I'm unsure what your application
> does to hit any conflict of that kind.

dlopen() so main will see arguments meant for xenomai_init() or you
need to no_auto_init and fiddle with /proc/cmdline and call xenomai_init

>   And ultimately it has to keep a list of
> > valid ones to do so pedanticly. If there are name clashes behaviour
> > is unclear. i.e. "--help" ld.so vs. dlopen
> >  
> 
> --help can be extended. See how testsuite/latency does for an example.

Help was just one example, you could have the same problem with any of
the other parameters.

> > 2.
> > The setup_descriptors do work but they rely on getting the order
> > stricly right. They have to execute before the first
> > xenomai_init(). In complex applications with multithreaded init
> > using dlopen() and auto-init-solib that quickly turns out to be
> > unusable. 
> 
> Well, I've been using setup descriptors on quite complex customer 
> applications (including lots of C++ static constructor braindamage),
> and never went into any dead end like you seem to imply since the
> latest additions in 3.0.5. Descriptors have their own priorities, and
> you may now use auto-bootstrappable libs as well.

I did not. I gave my customer multiple examples on how to set
mem-pool-size in static, ld.so and dlopen(). They have braindamage
static c++ with dlopen() and could not make it work. At the moment
their main() ignores any unknown argument so they can use 1. but that
needs to be fixed.

> > Suggestions:
> > 1.
> > 1.1 completely drop the support for parameters and the fiddling
> >     with /proc/cmdline
> > 1.2 or agree on a prefix "--xeno-" so the application can ignore all
> >     xenomai parameters without knowing all

You did not comment on that at all.

> > 2.
> > 2.1 completely drop the setup_descriptors in favour of environment
> >     variables
> >  
> 
> Hell no. Environment variables are crap. Unlike options which are 
> explicit, those things tend to pollute some hidden namespace, staying 
> there long after you stopped expecting them having any influence, set
> by dusty login scripts. That one is a strict nak for me, sorry.

Ok, that is a clear opinion and i get it. Let us not discuss env
variables anymore, but let us keep talking under that thread title ;).

> > That would be a drastic change but i think we should do something
> > about it. With environment variables it is clear what happens
> > without messing with the applications init or parameters, getting
> > rid of confusing complexity.
> >
> > Please let me know what you think, i would be happy to prepare
> > patches. 
> 
> What is the exact problem you face regarding options? Please also 
> remember that influencing the whole argument system only to support a 
> quite infrequent use case such as dlopen() is not the way to go. It's
> ok to find a solution that might fit all usages, it is not to
> introduce stuff that eases 1% of the use cases which badly affects
> 99% of the rest.

My customer switched to xenomai3 and they did not manage to set the
tuneables without hacks. I looked into setting them and found that
there are different ways and different behaviours for these ways
depending on how you link. They could not make it work ... Ok i can fix
it for them without talking to the community.

But i can do something about the fact that it is too complicated, and
that is what i am trying to do with this mail.

I would like to see only one way that always works the same no matter
how you link, no questions about who wins when multiple want to tune.
Maybe we can drop the "--auto-init-solib" switch eventually and just
make it default.

Imho 33% of the linking cases are broken, true that dlopen() is
probably not used a lot.

Henning

> PS: I'm supposedly off line at the moment, so follow ups may take
> some time to appear.
> 



  parent reply	other threads:[~2017-08-08 11:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-08  9:23 [Xenomai] [RFC] Xenomai3 tuneables replaced by environment variables Henning Schild
2017-08-08 10:24 ` Philippe Gerum
2017-08-08 11:35   ` Jan Kiszka
2017-08-08 11:48   ` Henning Schild [this message]
2017-08-08 18:05     ` Philippe Gerum
2017-08-08 19:27       ` Henning Schild
2017-08-16 18:13         ` Philippe Gerum
2017-08-21 11:12           ` Henning Schild
2017-08-21 13:25             ` Philippe Gerum
2017-08-25 17:16           ` Henning Schild
2017-08-29 11:05             ` Philippe Gerum
2017-08-29 12:27               ` Henning Schild
2017-08-29 16:10                 ` Philippe Gerum
2017-08-29 17:20                   ` Henning Schild
2017-08-29 20:02                     ` Philippe Gerum
2017-08-29 20:15                       ` Philippe Gerum
2017-08-30  7:42                       ` Henning Schild
2017-08-28  6:25 ` Stéphane Ancelot
2017-08-28  7:32   ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170808134801.59ae5de6@md1em3qc \
    --to=henning.schild@siemens.com \
    --cc=jan.kiszka@siemens.com \
    --cc=rpm@xenomai.org \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.