On 04/23/2013 01:20 PM, Gilles Chanteperdrix wrote:
On 04/23/2013 10:21 AM, Jan Kiszka wrote:
On 2013-04-22 20:57, Gilles Chanteperdrix wrote:
On 04/22/2013 03:42 PM, Jan Kiszka wrote:
On 2013-04-22 13:37, Gilles Chanteperdrix wrote:
On 04/22/2013 09:11 AM, Jan Kiszka wrote:
On 2013-04-20 17:30, Gilles Chanteperdrix wrote:
On 04/20/2013 05:27 PM, Jan Kiszka wrote:
On 2013-04-20 17:21, Gilles Chanteperdrix wrote:
On 04/20/2013 05:18 PM, Jan Kiszka wrote:
On 2013-04-20 17:14, Gilles Chanteperdrix wrote:
On 04/20/2013 10:19 AM, Jan Kiszka wrote:
On 2013-04-20 08:04, Michael Haberler wrote:
Am 19.04.2013 um 21:06 schrieb Gilles Chanteperdrix
<[email protected]>:
On 04/19/2013 01:46 PM, Leopold Palomo-Avellaneda wrote:
[1]
http://lists.mech.kuleuven.be/pipermail/orocos-users/2013-April/006986.html
Hi,
that link does not tell us why you need this option. And that would be
the most important information.
with the linuxcnc package build I need to turn on --enable-dlopen-skins as well
to get Python modules to work properly
OK, it looks like we should try harder to detect dlopen scenarios during
runtime to avoid build-time switches. This is likely Xenomai 3 material:
- We need to disable TLS optimizations by default (no big deal).
- In the POSIX skin constructor, we need to read out the mlockall
state, lock everything if necessary, and restore the state
accordingly afterward. The Nucleus may help us here if there is no
adequate libc service (ABI change -> Xenomai 3).
- IIRC, the problem with unconditional auto-shadowing back then were
the improper scheduling parameters that POSIX used to apply. That
was fixed a while back. So if we simple re-apply the current
parameters, it should cause no harm in a dlopen scenario. But I need
to check this again at work against our scenario.
You do not like the idea of an environment variable allowing to disable
the automatic shadowing?
Not as a long-term solution as it is user-unfriendly. But it can be an
option worth considering for 2.6.
Apparently -forge is already doing it. The advantage of this solution is
that the same binary serves well several usages, if we intend to provide
packages as generic as possible, this seems like the way to go. Several
of the changes I made in the last few weeks go in the same direction.
I'm not sure if there is added value for the controlling auto-shadowing
in general. But for the case it is in conflict with dlopen, the solution
I'm proposing is clearly superior as it removes those conflicts
automatically.
Of course, an environment variable control can exist in parallel if
there is a need beyond the dlopen conflict resolution.
The difference with what you propose is that you propose a syscall to
get the mlockall state. Another solution would be not to call munlockall
after the main thread shadowing, this looks less complicated and does
not require ABI changes.
Yes, that's an option as well. But then we should apply this
consistently, invoking mlockall from all skin init functions
unconditionally. The nucleus depends on this anyway. Not sure if such
change would be fine for 2.6 - you decide.
What we could do is:
- if XENO_NOSHADOW is set, shadow the main thread, and call mlockall
- if it is not set, do not shadow the main thread or call
mlockall/munlockall
That's not what I suggested. I was questioning the value of _not_ doing
mlockall automatically during init, thus reducing user duties. That
would reduce the need to think about XENO_NOSHADOW or not as a normal user.
Currently, when the posix skin library start, it does:
mlockall
shadow main thread
munlockall
Now, the munlockall is certainly an issue when dlopening
What I propose instead is to do:
if (!getenv("XENO_NOSHADOW")) {
mlockall
shadow main thread
}
That will avoid the problem with calling munlockall, and if people who
currently use --enable-dlopen-skins really want to avoid shadowing the
main thread (which I doubt), they can set the environment variable
XENO_NOSHADOW.
Totally clear. But why still requiring the application to call mlockall
if we do not autoshadow or use a different skin? It's pointless to have
this explicit call in the application if we can easily do this from the
library.
Well, we have --enable-posix-auto-mlockall for that. But you are right,
we get rid of all this and enable automatic mlockall for all skins. I do
not see any drawbacks.
From the dept of Xenomai archive: the original intent of controlling
when and how memory locking is done was to address this bug with very
old kernels:
http://lkml.indiana.edu/hypermail/linux/kernel/0310.0/0649.html
Back then, apps mmapping I/O space would then mlock(MCL_CURRENT),
mmap(I/O space), then mlock(MCL_FUTURE) to work around this bug manually.
--
Philippe.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
