From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <51758816.4050100@xenomai.org> Date: Mon, 22 Apr 2013 20:57:26 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <201304191346.38739.leo@alaxarxa.net> <517195B6.8020209@xenomai.org> <12ABCC03-FADF-4C5A-9CAE-CD9E5CA63A19@mah.priv.at> <51724F82.2000809@web.de> <5172B0E5.7090806@xenomai.org> <5172B1B5.10804@web.de> <5172B28C.6070503@xenomai.org> <5172B3CD.20007@web.de> <5172B4AA.1060704@xenomai.org> <5174E2A0.1040906@siemens.com> <51752114.7040903@xenomai.org> <51753E59.4090609@siemens.com> In-Reply-To: <51753E59.4090609@siemens.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Default options in the debian package List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "xenomai@xenomai.org" 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 : >>>>>>>>>> >>>>>>>>>>> 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. -- Gilles.