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