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. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
