Re: [Xenomai] Default options in the debian package

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2013-04-23 13:20, 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 <gilles.chanteperdrix@xenomai.org>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.

Perfect. Will work out some patches.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux