[Xenomai-core] [PATCH v2 0/4] Various fixes and cleanups

[Xenomai-core] [PATCH v2 0/4] Various fixes and cleanups

[Jan Kiszka]

This is a rework/rebase of the patch series I sent last December,
addressing the concerns and suggestions brought up during our discussion
in January.


Find the patches also at git://git.kiszka.org/xenomai.git queues/assorted

Jan Kiszka (4):
      POSIX: Fix SCHED_RR thread creation
      Mark libs nodlopen on initial-exec TLS
      Add --enable-dlopen-skins configure switch
      POSIX: Do not auto-shadow main with dlopen enabled

 configure.in                  |   22 +++++++++++++++++++-
 ksrc/skins/posix/syscall.c    |    4 +-
 src/skins/native/Makefile.am  |    2 +-
 src/skins/posix/Makefile.am   |    2 +-
 src/skins/posix/init.c        |   43 ++++++++++++++++++++++++++--------------
 src/skins/posix/thread.c      |   11 +++++----
 src/skins/psos+/Makefile.am   |    2 +-
 src/skins/rtai/Makefile.am    |    2 +-
 src/skins/rtdm/Makefile.am    |    2 +-
 src/skins/uitron/Makefile.am  |    2 +-
 src/skins/vrtx/Makefile.am    |    2 +-
 src/skins/vxworks/Makefile.am |    2 +-
 12 files changed, 64 insertions(+), 32 deletions(-)

--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

[Xenomai-core] [PATCH v2 4/4] POSIX: Do not auto-shadow main with dlopen enabled

[Jan Kiszka]

Don't perform auto-shadowing in POSIX skin if we might be loaded via
dlopen. Otherwise the wrong thread, the undefined dlopen caller, may be
(re-)shadowed, assigning wrong scheduling settings.

Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---

 src/skins/posix/init.c |   43 ++++++++++++++++++++++++++++---------------
 1 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
index 8fc5a92..b04dbf0 100644
--- a/src/skins/posix/init.c
+++ b/src/skins/posix/init.c
@@ -47,7 +47,6 @@ void pse51_clock_init(int);
 static __attribute__ ((constructor))
 void __init_posix_interface(void)
 {
-	struct sched_param parm;
 	int muxid, err;
 
 	muxid =
@@ -67,28 +66,42 @@ void __init_posix_interface(void)
 								 __rtdm_fdcount);
 	}
 
-	/* Shadow the main thread. mlock the whole memory for the time of the
-	   syscall, in order to avoid the SIGXCPU signal. */
+#ifdef CONFIG_XENO_LIBS_DLOPEN
+	/* Don't use auto-shadowing if we are likely invoked from dlopen, but
+	   take care of auto-mlockall. */
+#ifdef CONFIG_XENO_POSIX_AUTO_MLOCKALL
 	if (mlockall(MCL_CURRENT | MCL_FUTURE)) {
 		perror("Xenomai Posix skin init: mlockall");
 		exit(EXIT_FAILURE);
 	}
+#endif /* CONFIG_XENO_POSIX_AUTO_MLOCKALL */
+#else /* !CONFIG_XENO_LIBS_DLOPEN */
+	{
+		struct sched_param parm = { .sched_priority = 0 };
+
+		/* Shadow the main thread. mlock the whole memory for the time
+		   of the syscall, in order to avoid the SIGXCPU signal. */
+		if (mlockall(MCL_CURRENT | MCL_FUTURE)) {
+			perror("Xenomai Posix skin init: mlockall");
+			exit(EXIT_FAILURE);
+		}
 
-	parm.sched_priority = 0;
-	err = __wrap_pthread_setschedparam(pthread_self(), SCHED_OTHER,
-					   &parm);
-	if (err) {
-		fprintf(stderr, "Xenomai Posix skin init: "
-			"pthread_setschedparam: %s\n", strerror(err));
-		exit(EXIT_FAILURE);
-	}
+		err = __wrap_pthread_setschedparam(pthread_self(), SCHED_OTHER,
+						   &parm);
+		if (err) {
+			fprintf(stderr, "Xenomai Posix skin init: "
+				"pthread_setschedparam: %s\n", strerror(err));
+			exit(EXIT_FAILURE);
+		}
 
 #ifndef CONFIG_XENO_POSIX_AUTO_MLOCKALL
-	if (munlockall()) {
-		perror("Xenomai Posix skin init: munlockall");
-		exit(EXIT_FAILURE);
-	}
+		if (munlockall()) {
+			perror("Xenomai Posix skin init: munlockall");
+			exit(EXIT_FAILURE);
+		}
 #endif /* !CONFIG_XENO_POSIX_AUTO_MLOCKALL */
+	}
+#endif /* !CONFIG_XENO_LIBS_DLOPEN */
 
 	if (!fork_handler_registered) {
 		err = pthread_atfork(NULL, NULL, &__init_posix_interface);

[Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Jan Kiszka]

SCHED_RR threads created via pthread_create do not receive the
round-robin property at kernel side. Fix this by pushing the policy as
an additional argument to __pse51_thread_create down to the kernel.
Moreover, enforce SCHED_FIFO for the Linux part of those threads.

Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---

 ksrc/skins/posix/syscall.c |    4 ++--
 src/skins/posix/thread.c   |   11 ++++++-----
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/ksrc/skins/posix/syscall.c b/ksrc/skins/posix/syscall.c
index 99c2a16..3480142 100644
--- a/ksrc/skins/posix/syscall.c
+++ b/ksrc/skins/posix/syscall.c
@@ -167,7 +167,7 @@ static int __pthread_create(struct pt_regs *regs)
 	   calling context. */
 
 	pthread_attr_init(&attr);
-	attr.policy = p->policy;
+	attr.policy = __xn_reg_arg2(regs);
 	attr.detachstate = PTHREAD_CREATE_DETACHED;
 	attr.schedparam_ex.sched_priority = p->rt_priority;
 	attr.fp = 1;
@@ -179,7 +179,7 @@ static int __pthread_create(struct pt_regs *regs)
 		return -err;	/* Conventionally, our error codes are negative. */
 
 	err = xnshadow_map(&k_tid->threadbase, NULL,
-			   (unsigned long __user *)__xn_reg_arg2(regs));
+			   (unsigned long __user *)__xn_reg_arg3(regs));
 
 	if (!err && !__pthread_hash(&hkey, k_tid))
 		err = -ENOMEM;
diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
index f32c7e1..4cf4e1c 100644
--- a/src/skins/posix/thread.c
+++ b/src/skins/posix/thread.c
@@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
 
 	param.sched_priority = iargs->prio;
 	policy = iargs->policy;
+	if (policy == SCHED_RR)
+		/* Restrict round-robin scheduling to the Xenomai domain. */
+		policy = SCHED_FIFO;
 	parent_prio = iargs->parent_prio;
 	mode_buf = xeno_init_current_mode();
 
@@ -203,8 +206,8 @@ static void *__pthread_trampoline(void *arg)
 
 	/* Do _not_ inline the call to pthread_self() in the syscall
 	   macro: this trashes the syscall regs on some archs. */
-	err = XENOMAI_SKINCALL2(__pse51_muxid, __pse51_thread_create, tid,
-				mode_buf);
+	err = XENOMAI_SKINCALL3(__pse51_muxid, __pse51_thread_create, tid,
+				iargs->policy, mode_buf);
 	iargs->ret = -err;
 
 	/* We must save anything we'll need to use from *iargs on our own
@@ -221,9 +224,7 @@ static void *__pthread_trampoline(void *arg)
 	__real_sem_post(&iargs->sync);
 
 	if (!err) {
-		/* Broken pthread libs ignore some of the thread attribute specs
-		   passed to pthread_create(3), so we force the scheduling policy
-		   once again here. */
+		/* Adjust to final Linux policy and priority. */
 		__real_pthread_setschedparam(tid, policy, &param);
 
 		/* If the thread running pthread_create runs with the same

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>  
>  	param.sched_priority = iargs->prio;
>  	policy = iargs->policy;
> +	if (policy == SCHED_RR)
> +		/* Restrict round-robin scheduling to the Xenomai domain. */
> +		policy = SCHED_FIFO;

Should not there be the same thing in __wrap_pthread_setschedparam ?
-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>  
>>  	param.sched_priority = iargs->prio;
>>  	policy = iargs->policy;
>> +	if (policy == SCHED_RR)
>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>> +		policy = SCHED_FIFO;
> 
> Should not there be the same thing in __wrap_pthread_setschedparam ?

Yes, and setschedparam_ex, here we go:

--------->

SCHED_RR threads created via pthread_create do not receive the
round-robin property at kernel side. Fix this by pushing the policy as
an additional argument to __pse51_thread_create down to the kernel.
Moreover, enforce SCHED_FIFO for the Linux part of those threads.

Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---

 0 files changed, 0 insertions(+), 0 deletions(-)

diff --git a/ksrc/skins/posix/syscall.c b/ksrc/skins/posix/syscall.c
index 99c2a16..3480142 100644
--- a/ksrc/skins/posix/syscall.c
+++ b/ksrc/skins/posix/syscall.c
@@ -167,7 +167,7 @@ static int __pthread_create(struct pt_regs *regs)
 	   calling context. */
 
 	pthread_attr_init(&attr);
-	attr.policy = p->policy;
+	attr.policy = __xn_reg_arg2(regs);
 	attr.detachstate = PTHREAD_CREATE_DETACHED;
 	attr.schedparam_ex.sched_priority = p->rt_priority;
 	attr.fp = 1;
@@ -179,7 +179,7 @@ static int __pthread_create(struct pt_regs *regs)
 		return -err;	/* Conventionally, our error codes are negative. */
 
 	err = xnshadow_map(&k_tid->threadbase, NULL,
-			   (unsigned long __user *)__xn_reg_arg2(regs));
+			   (unsigned long __user *)__xn_reg_arg3(regs));
 
 	if (!err && !__pthread_hash(&hkey, k_tid))
 		err = -ENOMEM;
diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
index f32c7e1..1593eea 100644
--- a/src/skins/posix/thread.c
+++ b/src/skins/posix/thread.c
@@ -61,8 +61,13 @@ int __wrap_pthread_setschedparam(pthread_t thread,
 				 __pse51_thread_setschedparam,
 				 thread, policy, param, mode_buf, &promoted);
 
-	if (err == EPERM)
+	if (err == EPERM) {
+		if (policy == SCHED_RR)
+			/* Restrict round-robin scheduling to the Xenomai
+			   domain. */
+			policy = SCHED_FIFO;
 		return __real_pthread_setschedparam(thread, policy, param);
+	}
 
 	if (!err && promoted) {
 		sigshadow_install_once();
@@ -104,6 +109,10 @@ int pthread_setschedparam_ex(pthread_t thread,
 
 	if (err == EPERM) {
 		short_param.sched_priority = param->sched_priority;
+		if (policy == SCHED_RR)
+			/* Restrict round-robin scheduling to the Xenomai
+			   domain. */
+			policy = SCHED_FIFO;
 		return __real_pthread_setschedparam(thread, policy, &short_param);
 	}
 
@@ -192,6 +201,9 @@ static void *__pthread_trampoline(void *arg)
 
 	param.sched_priority = iargs->prio;
 	policy = iargs->policy;
+	if (policy == SCHED_RR)
+		/* Restrict round-robin scheduling to the Xenomai domain. */
+		policy = SCHED_FIFO;
 	parent_prio = iargs->parent_prio;
 	mode_buf = xeno_init_current_mode();
 
@@ -203,8 +215,8 @@ static void *__pthread_trampoline(void *arg)
 
 	/* Do _not_ inline the call to pthread_self() in the syscall
 	   macro: this trashes the syscall regs on some archs. */
-	err = XENOMAI_SKINCALL2(__pse51_muxid, __pse51_thread_create, tid,
-				mode_buf);
+	err = XENOMAI_SKINCALL3(__pse51_muxid, __pse51_thread_create, tid,
+				iargs->policy, mode_buf);
 	iargs->ret = -err;
 
 	/* We must save anything we'll need to use from *iargs on our own
@@ -221,9 +233,7 @@ static void *__pthread_trampoline(void *arg)
 	__real_sem_post(&iargs->sync);
 
 	if (!err) {
-		/* Broken pthread libs ignore some of the thread attribute specs
-		   passed to pthread_create(3), so we force the scheduling policy
-		   once again here. */
+		/* Adjust to final Linux policy and priority. */
 		__real_pthread_setschedparam(tid, policy, &param);
 
 		/* If the thread running pthread_create runs with the same

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>  
>>>  	param.sched_priority = iargs->prio;
>>>  	policy = iargs->policy;
>>> +	if (policy == SCHED_RR)
>>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>>> +		policy = SCHED_FIFO;
>> Should not there be the same thing in __wrap_pthread_setschedparam ?
> 
> Yes, and setschedparam_ex, here we go:

Actually, I am wondering if we can not get rid of these calls to
__real_pthread_setschedparam, now that propagating kernel-space priority
to user-space is done by a signal ?

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>>  
>>>>  	param.sched_priority = iargs->prio;
>>>>  	policy = iargs->policy;
>>>> +	if (policy == SCHED_RR)
>>>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>>>> +		policy = SCHED_FIFO;
>>> Should not there be the same thing in __wrap_pthread_setschedparam ?
>> Yes, and setschedparam_ex, here we go:
> 
> Actually, I am wondering if we can not get rid of these calls to
> __real_pthread_setschedparam, now that propagating kernel-space priority
> to user-space is done by a signal ?

Not with the existing code, as that only forwards prio changes, but no
policy changes.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>>>  
>>>>>  	param.sched_priority = iargs->prio;
>>>>>  	policy = iargs->policy;
>>>>> +	if (policy == SCHED_RR)
>>>>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>>>>> +		policy = SCHED_FIFO;
>>>> Should not there be the same thing in __wrap_pthread_setschedparam ?
>>> Yes, and setschedparam_ex, here we go:
>> Actually, I am wondering if we can not get rid of these calls to
>> __real_pthread_setschedparam, now that propagating kernel-space priority
>> to user-space is done by a signal ?
> 
> Not with the existing code, as that only forwards prio changes, but no
> policy changes.

If we map SCHED_RR to SCHED_FIFO, are there any policy changes?

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>>>>  
>>>>>>  	param.sched_priority = iargs->prio;
>>>>>>  	policy = iargs->policy;
>>>>>> +	if (policy == SCHED_RR)
>>>>>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>>>>>> +		policy = SCHED_FIFO;
>>>>> Should not there be the same thing in __wrap_pthread_setschedparam ?
>>>> Yes, and setschedparam_ex, here we go:
>>> Actually, I am wondering if we can not get rid of these calls to
>>> __real_pthread_setschedparam, now that propagating kernel-space priority
>>> to user-space is done by a signal ?
>> Not with the existing code, as that only forwards prio changes, but no
>> policy changes.
> 
> If we map SCHED_RR to SCHED_FIFO, are there any policy changes?

Yes, the initial one. Keep in mind that not all pthread implementations
may respect the pthread_attr or have problems assigning SCHED_FIFO to
threads of non-root users.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>>>>>  
>>>>>>>  	param.sched_priority = iargs->prio;
>>>>>>>  	policy = iargs->policy;
>>>>>>> +	if (policy == SCHED_RR)
>>>>>>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>>>>>>> +		policy = SCHED_FIFO;
>>>>>> Should not there be the same thing in __wrap_pthread_setschedparam ?
>>>>> Yes, and setschedparam_ex, here we go:
>>>> Actually, I am wondering if we can not get rid of these calls to
>>>> __real_pthread_setschedparam, now that propagating kernel-space priority
>>>> to user-space is done by a signal ?
>>> Not with the existing code, as that only forwards prio changes, but no
>>> policy changes.
>> If we map SCHED_RR to SCHED_FIFO, are there any policy changes?
> 
> Yes, the initial one. Keep in mind that not all pthread implementations
> may respect the pthread_attr or have problems assigning SCHED_FIFO to
> threads of non-root users.

Ok. What about calling xnshadow_renice in xnshadow_map ?

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> Jan Kiszka wrote:
>>>>>>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>>>>>>  
>>>>>>>>  	param.sched_priority = iargs->prio;
>>>>>>>>  	policy = iargs->policy;
>>>>>>>> +	if (policy == SCHED_RR)
>>>>>>>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>>>>>>>> +		policy = SCHED_FIFO;
>>>>>>> Should not there be the same thing in __wrap_pthread_setschedparam ?
>>>>>> Yes, and setschedparam_ex, here we go:
>>>>> Actually, I am wondering if we can not get rid of these calls to
>>>>> __real_pthread_setschedparam, now that propagating kernel-space priority
>>>>> to user-space is done by a signal ?
>>>> Not with the existing code, as that only forwards prio changes, but no
>>>> policy changes.
>>> If we map SCHED_RR to SCHED_FIFO, are there any policy changes?
>> Yes, the initial one. Keep in mind that not all pthread implementations
>> may respect the pthread_attr or have problems assigning SCHED_FIFO to
>> threads of non-root users.
> 
> Ok. What about calling xnshadow_renice in xnshadow_map ?

Sorry, I can't follow. xnshadow_renice does not help user space to find
the right policy, or what do you mean?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>> Jan Kiszka wrote:
>>>>>>>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>>>>>>>  
>>>>>>>>>  	param.sched_priority = iargs->prio;
>>>>>>>>>  	policy = iargs->policy;
>>>>>>>>> +	if (policy == SCHED_RR)
>>>>>>>>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>>>>>>>>> +		policy = SCHED_FIFO;
>>>>>>>> Should not there be the same thing in __wrap_pthread_setschedparam ?
>>>>>>> Yes, and setschedparam_ex, here we go:
>>>>>> Actually, I am wondering if we can not get rid of these calls to
>>>>>> __real_pthread_setschedparam, now that propagating kernel-space priority
>>>>>> to user-space is done by a signal ?
>>>>> Not with the existing code, as that only forwards prio changes, but no
>>>>> policy changes.
>>>> If we map SCHED_RR to SCHED_FIFO, are there any policy changes?
>>> Yes, the initial one. Keep in mind that not all pthread implementations
>>> may respect the pthread_attr or have problems assigning SCHED_FIFO to
>>> threads of non-root users.
>> Ok. What about calling xnshadow_renice in xnshadow_map ?
> 
> Sorry, I can't follow. xnshadow_renice does not help user space to find
> the right policy, or what do you mean?

xnshadow_renice sends a signal to the user-space thread which in turn
calls __real_pthread_setschedparam.

The advantage of this solution is that it avoids calling
__real_pthread_setschedparam in many places in the user-space skins.

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> Jan Kiszka wrote:
>>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>>> Jan Kiszka wrote:
>>>>>>>>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>>>>>>>>  
>>>>>>>>>>  	param.sched_priority = iargs->prio;
>>>>>>>>>>  	policy = iargs->policy;
>>>>>>>>>> +	if (policy == SCHED_RR)
>>>>>>>>>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>>>>>>>>>> +		policy = SCHED_FIFO;
>>>>>>>>> Should not there be the same thing in __wrap_pthread_setschedparam ?
>>>>>>>> Yes, and setschedparam_ex, here we go:
>>>>>>> Actually, I am wondering if we can not get rid of these calls to
>>>>>>> __real_pthread_setschedparam, now that propagating kernel-space priority
>>>>>>> to user-space is done by a signal ?
>>>>>> Not with the existing code, as that only forwards prio changes, but no
>>>>>> policy changes.
>>>>> If we map SCHED_RR to SCHED_FIFO, are there any policy changes?
>>>> Yes, the initial one. Keep in mind that not all pthread implementations
>>>> may respect the pthread_attr or have problems assigning SCHED_FIFO to
>>>> threads of non-root users.
>>> Ok. What about calling xnshadow_renice in xnshadow_map ?
>> Sorry, I can't follow. xnshadow_renice does not help user space to find
>> the right policy, or what do you mean?
> 
> xnshadow_renice sends a signal to the user-space thread which in turn
> calls __real_pthread_setschedparam.

Ah, and user space derives the policy from the prio. That's what I missed.

> 
> The advantage of this solution is that it avoids calling
> __real_pthread_setschedparam in many places in the user-space skins.

We would save the call in the trampolines at least (my other changes in
the second revision were nonsense BTW - those paths belong to the
non-Xenomai case). We would just have to pass the priority down on
pthread_create as well.

Will look into this and come up with a new version for this patch. But
that need not delay merging the others.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2877 bytes --]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>> Jan Kiszka wrote:
>>>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>>>> Jan Kiszka wrote:
>>>>>>>>>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>>>>>>>>>  
>>>>>>>>>>>  	param.sched_priority = iargs->prio;
>>>>>>>>>>>  	policy = iargs->policy;
>>>>>>>>>>> +	if (policy == SCHED_RR)
>>>>>>>>>>> +		/* Restrict round-robin scheduling to the Xenomai domain. */
>>>>>>>>>>> +		policy = SCHED_FIFO;
>>>>>>>>>> Should not there be the same thing in __wrap_pthread_setschedparam ?
>>>>>>>>> Yes, and setschedparam_ex, here we go:
>>>>>>>> Actually, I am wondering if we can not get rid of these calls to
>>>>>>>> __real_pthread_setschedparam, now that propagating kernel-space priority
>>>>>>>> to user-space is done by a signal ?
>>>>>>> Not with the existing code, as that only forwards prio changes, but no
>>>>>>> policy changes.
>>>>>> If we map SCHED_RR to SCHED_FIFO, are there any policy changes?
>>>>> Yes, the initial one. Keep in mind that not all pthread implementations
>>>>> may respect the pthread_attr or have problems assigning SCHED_FIFO to
>>>>> threads of non-root users.
>>>> Ok. What about calling xnshadow_renice in xnshadow_map ?
>>> Sorry, I can't follow. xnshadow_renice does not help user space to find
>>> the right policy, or what do you mean?
>> xnshadow_renice sends a signal to the user-space thread which in turn
>> calls __real_pthread_setschedparam.
> 
> Ah, and user space derives the policy from the prio. That's what I missed.
> 
>> The advantage of this solution is that it avoids calling
>> __real_pthread_setschedparam in many places in the user-space skins.
> 
> We would save the call in the trampolines at least (my other changes in
> the second revision were nonsense BTW - those paths belong to the
> non-Xenomai case). We would just have to pass the priority down on
> pthread_create as well.
> 
> Will look into this and come up with a new version for this patch. But
> that need not delay merging the others.

I played with it, but raising a signal from xnshadow_map is no good
idea: If we inject the signal before the migration, xnshadow_map fails
due to the pending signal, we exit to user space, run the signal,
restart the call, raise the signal, and so on. If we raise after
migration, we immediately force the new thread into secondary mode
again, definitely causing problems when the mode switch warning is
active, but also risking other regressions for xnshadow_map users that
expect to find themselves in primary mode on return.

In short: I think it is better to stick with my original version of this
patch.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] [PATCH v2 1/4] POSIX: Fix SCHED_RR thread creation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 9990 bytes --]

Jan Kiszka wrote:
> I played with it, but raising a signal from xnshadow_map is no good
> idea: If we inject the signal before the migration, xnshadow_map fails
> due to the pending signal, we exit to user space, run the signal,
> restart the call, raise the signal, and so on. If we raise after
> migration, we immediately force the new thread into secondary mode
> again, definitely causing problems when the mode switch warning is
> active, but also risking other regressions for xnshadow_map users that
> expect to find themselves in primary mode on return.
> 

Meditating over it again, I realized that there is actually no need to
raise the renice signal if we migrate in xnshadow_map. This case will be
handled automatically on next relax. That pattern seems to work and
allows indeed a few cleanups (just uitron still needs
pthread_setschedparam). This is just a first draft, needs more testing:

diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index 8c679ad..f0f6801 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -1250,6 +1250,12 @@ int xnshadow_map(xnthread_t *thread, xncompletion_t __user *u_completion,
 	thread->u_mode = u_mode;
 
 	if (u_completion) {
+		/*
+		 * Send the renice signal if we are not migrating so that user
+		 * space will immediately align Linux sched policy and prio.
+		 */
+		xnshadow_renice(thread);
+
  		/*
 		 * We still have the XNDORMANT bit set, so we can't
  		 * link to the RPI queue which only links _runnable_
diff --git a/ksrc/skins/posix/syscall.c b/ksrc/skins/posix/syscall.c
index 99c2a16..16303b3 100644
--- a/ksrc/skins/posix/syscall.c
+++ b/ksrc/skins/posix/syscall.c
@@ -167,9 +167,9 @@ static int __pthread_create(struct pt_regs *regs)
 	   calling context. */
 
 	pthread_attr_init(&attr);
-	attr.policy = p->policy;
+	attr.policy = __xn_reg_arg2(regs);
 	attr.detachstate = PTHREAD_CREATE_DETACHED;
-	attr.schedparam_ex.sched_priority = p->rt_priority;
+	attr.schedparam_ex.sched_priority = __xn_reg_arg3(regs);
 	attr.fp = 1;
 	attr.name = p->comm;
 
@@ -179,7 +179,7 @@ static int __pthread_create(struct pt_regs *regs)
 		return -err;	/* Conventionally, our error codes are negative. */
 
 	err = xnshadow_map(&k_tid->threadbase, NULL,
-			   (unsigned long __user *)__xn_reg_arg2(regs));
+			   (unsigned long __user *)__xn_reg_arg4(regs));
 
 	if (!err && !__pthread_hash(&hkey, k_tid))
 		err = -ENOMEM;
diff --git a/src/skins/native/task.c b/src/skins/native/task.c
index 7bcc49c..190dc4b 100644
--- a/src/skins/native/task.c
+++ b/src/skins/native/task.c
@@ -55,21 +55,10 @@ static void *rt_task_trampoline(void *cookie)
 {
 	struct rt_task_iargs *iargs = (struct rt_task_iargs *)cookie;
 	void (*entry) (void *cookie);
-	struct sched_param param;
 	struct rt_arg_bulk bulk;
 	RT_TASK *task;
 	long err;
 
-	if (iargs->prio > 0) {
-		/*
-		 * Re-apply sched params here as some libpthread
-		 * implementations fail doing this via pthread_create.
-		 */
-		memset(&param, 0, sizeof(param));
-		param.sched_priority = iargs->prio;
-		__real_pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);
-	}
-
 	/* rt_task_delete requires asynchronous cancellation */
 	pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
 
@@ -178,7 +167,6 @@ int rt_task_start(RT_TASK *task, void (*entry) (void *cookie), void *cookie)
 
 int rt_task_shadow(RT_TASK *task, const char *name, int prio, int mode)
 {
-	struct sched_param param;
 	struct rt_arg_bulk bulk;
 	RT_TASK task_desc;
 	int err;
@@ -190,13 +178,6 @@ int rt_task_shadow(RT_TASK *task, const char *name, int prio, int mode)
 	pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
 	sigshadow_install_once();
 
-	if (prio > 0) {
-		/* Make sure the POSIX library caches the right priority. */
-		memset(&param, 0, sizeof(param));
-		param.sched_priority = prio;
-		__real_pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);
-	}
-
 	bulk.a1 = (u_long)task;
 	bulk.a2 = (u_long)name;
 	bulk.a3 = (u_long)prio;
diff --git a/src/skins/native/wrappers.c b/src/skins/native/wrappers.c
index 8421456..4463f6f 100644
--- a/src/skins/native/wrappers.c
+++ b/src/skins/native/wrappers.c
@@ -33,13 +33,6 @@
  */
 
 __attribute__ ((weak))
-int __real_pthread_setschedparam(pthread_t thread,
-				 int policy, const struct sched_param *param)
-{
-	return pthread_setschedparam(thread, policy, param);
-}
-
-__attribute__ ((weak))
 int __real_pthread_create(pthread_t *tid,
 			  const pthread_attr_t * attr,
 			  void *(*start) (void *), void *arg)
diff --git a/src/skins/native/wrappers.h b/src/skins/native/wrappers.h
index f2125a4..99568a9 100644
--- a/src/skins/native/wrappers.h
+++ b/src/skins/native/wrappers.h
@@ -8,9 +8,6 @@ int __real_pthread_create(pthread_t *tid,
 			  const pthread_attr_t * attr,
 			  void *(*start) (void *), void *arg);
 
-int __real_pthread_setschedparam(pthread_t thread,
-				 int policy, const struct sched_param *param);
-
 int __real_pthread_kill(pthread_t tid, int sig);
 
 int __real_open(const char *path, int oflag, ...);
diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
index f32c7e1..e8c50bd 100644
--- a/src/skins/posix/thread.c
+++ b/src/skins/posix/thread.c
@@ -203,8 +203,8 @@ static void *__pthread_trampoline(void *arg)
 
 	/* Do _not_ inline the call to pthread_self() in the syscall
 	   macro: this trashes the syscall regs on some archs. */
-	err = XENOMAI_SKINCALL2(__pse51_muxid, __pse51_thread_create, tid,
-				mode_buf);
+	err = XENOMAI_SKINCALL4(__pse51_muxid, __pse51_thread_create, tid,
+				iargs->policy, iargs->prio, mode_buf);
 	iargs->ret = -err;
 
 	/* We must save anything we'll need to use from *iargs on our own
@@ -221,11 +221,6 @@ static void *__pthread_trampoline(void *arg)
 	__real_sem_post(&iargs->sync);
 
 	if (!err) {
-		/* Broken pthread libs ignore some of the thread attribute specs
-		   passed to pthread_create(3), so we force the scheduling policy
-		   once again here. */
-		__real_pthread_setschedparam(tid, policy, &param);
-
 		/* If the thread running pthread_create runs with the same
 		   priority as us, we should leave it running, as if there never
 		   was a synchronization with a semaphore. */
diff --git a/src/skins/psos+/task.c b/src/skins/psos+/task.c
index 265eab2..1bf3565 100644
--- a/src/skins/psos+/task.c
+++ b/src/skins/psos+/task.c
@@ -63,13 +63,8 @@ static void *psos_task_trampoline(void *cookie)
 	void (*entry)(u_long, u_long, u_long, u_long);
 	u_long dummy_args[4] = { 0, 0, 0, 0 }, *targs;
 	struct psos_arg_bulk bulk;
-	struct sched_param param;
-	int policy;
 	long err;
 
-	policy = psos_task_set_posix_priority(iargs->prio, &param);
-	pthread_setschedparam(pthread_self(), policy, &param);
-
 	pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
 	sigshadow_install_once();
 
diff --git a/src/skins/vrtx/task.c b/src/skins/vrtx/task.c
index 1b16f68..184c948 100644
--- a/src/skins/vrtx/task.c
+++ b/src/skins/vrtx/task.c
@@ -73,8 +73,6 @@ static void *vrtx_task_trampoline(void *cookie)
 	struct vrtx_task_iargs *iargs =
 	    (struct vrtx_task_iargs *)cookie, _iargs;
 	struct vrtx_arg_bulk bulk;
-	struct sched_param param;
-	int policy;
 	long err;
 #ifndef HAVE___THREAD
 	TCB *tcb;
@@ -83,13 +81,6 @@ static void *vrtx_task_trampoline(void *cookie)
 	/* Backup the arg struct, it might vanish after completion. */
 	memcpy(&_iargs, iargs, sizeof(_iargs));
 
-	/*
-	 * Apply sched params here as some libpthread implementations
-	 * fail doing this properly via pthread_create.
-	 */
-	policy = vrtx_task_set_posix_priority(iargs->prio, &param);
-	pthread_setschedparam(pthread_self(), policy, &param);
-
 	/* vrtx_task_delete requires asynchronous cancellation */
 	pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
 
diff --git a/src/skins/vxworks/taskLib.c b/src/skins/vxworks/taskLib.c
index 1ba193e..3249bfc 100644
--- a/src/skins/vxworks/taskLib.c
+++ b/src/skins/vxworks/taskLib.c
@@ -86,21 +86,12 @@ static void *wind_task_trampoline(void *cookie)
 	struct wind_task_iargs *iargs =
 	    (struct wind_task_iargs *)cookie, _iargs;
 	struct wind_arg_bulk bulk;
-	struct sched_param param;
 	WIND_TCB *pTcb;
-	int policy;
 	long err;
 
 	/* Backup the arg struct, it might vanish after completion. */
 	memcpy(&_iargs, iargs, sizeof(_iargs));
 
-	/*
-	 * Apply sched params here as some libpthread implementations
-	 * fail doing this properly via pthread_create.
-	 */
-	policy = wind_task_set_posix_priority(iargs->prio, &param);
-	__real_pthread_setschedparam(pthread_self(), policy, &param);
-
 	/* wind_task_delete requires asynchronous cancellation */
 	pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
 	sigshadow_install_once();
diff --git a/src/skins/vxworks/wrappers.c b/src/skins/vxworks/wrappers.c
index 394ea51..ab50d77 100644
--- a/src/skins/vxworks/wrappers.c
+++ b/src/skins/vxworks/wrappers.c
@@ -33,13 +33,6 @@
  */
 
 __attribute__ ((weak))
-int __real_pthread_setschedparam(pthread_t thread,
-				 int policy, const struct sched_param *param)
-{
-	return pthread_setschedparam(thread, policy, param);
-}
-
-__attribute__ ((weak))
 int __real_pthread_create(pthread_t *tid,
 			  const pthread_attr_t * attr,
 			  void *(*start) (void *), void *arg)
diff --git a/src/skins/vxworks/wrappers.h b/src/skins/vxworks/wrappers.h
index 919309a..e20da86 100644
--- a/src/skins/vxworks/wrappers.h
+++ b/src/skins/vxworks/wrappers.h
@@ -8,9 +8,6 @@ int __real_pthread_create(pthread_t *tid,
 			  const pthread_attr_t * attr,
 			  void *(*start) (void *), void *arg);
 
-int __real_pthread_setschedparam(pthread_t thread,
-				 int policy, const struct sched_param *param);
-
 int __real_pthread_kill(pthread_t tid, int sig);
 
 int __real_open(const char *path, int oflag, ...);


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Xenomai-core] [PATCH v2 3/4] Add --enable-dlopen-skins configure switch

[Jan Kiszka]

To clarify the relation between disabling TLS support and allowing to
dlopen Xenomai skin library, introduce an explicit configure switch.
This way we will also have a control to disable auto-shadowing in the
POSIX skin for dlopen scenarios.

Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---

 configure.in |   19 +++++++++++++++++--
 1 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/configure.in b/configure.in
index 1d7f5fa..679af96 100644
--- a/configure.in
+++ b/configure.in
@@ -758,15 +758,30 @@ LIBS="$LIBS -lrt"
 AC_CHECK_FUNCS([shm_open shm_unlink])
 LIBS="$save_LIBS"
 
+AC_MSG_CHECKING(whether to enable dlopen support for skin libraries)
+AC_ARG_ENABLE(dlopen-skins,
+	AC_HELP_STRING([--enable-dlopen-skins], [Disable TLS features and
+automatic main thread mapping by the POSIX skin to allows dlopen'ing Xenomai
+libs.]),
+	[case "$enableval" in
+	y | yes) CONFIG_XENO_LIBS_DLOPEN=y ;;
+	*) unset CONFIG_XENO_LIBS_DLOPEN ;;
+	esac])
+AC_MSG_RESULT(${CONFIG_XENO_LIBS_DLOPEN:-no})
+if test x$CONFIG_XENO_LIBS_DLOPEN = xy; then
+	AC_DEFINE(CONFIG_XENO_LIBS_DLOPEN,1,[config])
+fi
+
 XENO_DLOPEN_CONSTRAINT=
+
 AC_ARG_WITH([__thread],
 	    AC_HELP_STRING([--without-__thread],
-			   [do not use TLS features (allows for dlopen'ing Xenomai libs)]),
+			   [do not use TLS features]),
 	    [use__thread=$withval],
 	    [use__thread=yes])
 
 dnl Check whether the compiler supports the __thread keyword.
-if test "x$use__thread" != xno; then
+if test "x$use__thread" != xno -a "x$CONFIG_XENO_LIBS_DLOPEN" != xy; then
 	AC_CACHE_CHECK([for __thread], libc_cv_gcc___thread,
 	[cat > conftest.c <<\EOF
 __thread int a __attribute__ ((tls_model ("initial-exec"))) = 42;

[Xenomai-core] [PATCH v2 2/4] Mark libs nodlopen on initial-exec TLS

[Jan Kiszka]

Mark libs with nodlopen if initial-exec __thread variables are used
because dlopen and this TLS model are in conflict.

Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---

 configure.in                  |    3 +++
 src/skins/native/Makefile.am  |    2 +-
 src/skins/posix/Makefile.am   |    2 +-
 src/skins/psos+/Makefile.am   |    2 +-
 src/skins/rtai/Makefile.am    |    2 +-
 src/skins/rtdm/Makefile.am    |    2 +-
 src/skins/uitron/Makefile.am  |    2 +-
 src/skins/vrtx/Makefile.am    |    2 +-
 src/skins/vxworks/Makefile.am |    2 +-
 9 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/configure.in b/configure.in
index c111c4a..1d7f5fa 100644
--- a/configure.in
+++ b/configure.in
@@ -758,6 +758,7 @@ LIBS="$LIBS -lrt"
 AC_CHECK_FUNCS([shm_open shm_unlink])
 LIBS="$save_LIBS"
 
+XENO_DLOPEN_CONSTRAINT=
 AC_ARG_WITH([__thread],
 	    AC_HELP_STRING([--without-__thread],
 			   [do not use TLS features (allows for dlopen'ing Xenomai libs)]),
@@ -778,6 +779,7 @@ EOF
 	rm -f conftest*])
 	if test "$libc_cv_gcc___thread" = yes; then
 		AC_DEFINE(HAVE___THREAD,1,[config])
+		XENO_DLOPEN_CONSTRAINT="-Wl,-z -Wl,nodlopen"
 	fi
 fi
 
@@ -799,6 +801,7 @@ AC_SUBST(XENO_USER_CFLAGS)
 AC_SUBST(XENO_USER_LDFLAGS)
 AC_SUBST(XENO_USER_APP_CFLAGS)
 AC_SUBST(XENO_USER_APP_LDFLAGS)
+AC_SUBST(XENO_DLOPEN_CONSTRAINT)
 AC_SUBST([CONFIG_STATUS_DEPENDENCIES],
         ['$(top_srcdir)/src/skins/posix/posix.wrappers'])
 AC_SUBST(XENO_POSIX_WRAPPERS)
diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am
index a1f61d9..3497f90 100644
--- a/src/skins/native/Makefile.am
+++ b/src/skins/native/Makefile.am
@@ -1,6 +1,6 @@
 lib_LTLIBRARIES = libnative.la
 
-libnative_la_LDFLAGS = -version-info 3:0:0 -lpthread
+libnative_la_LDFLAGS = @XENO_DLOPEN_CONSTRAINT@ -version-info 3:0:0 -lpthread
 
 libnative_la_SOURCES = \
 	alarm.c \
diff --git a/src/skins/posix/Makefile.am b/src/skins/posix/Makefile.am
index 2d42a28..d6a0912 100644
--- a/src/skins/posix/Makefile.am
+++ b/src/skins/posix/Makefile.am
@@ -4,7 +4,7 @@ lib_LTLIBRARIES = libpthread_rt.la
 
 CPPFLAGS+=-I$(top_srcdir)/ksrc/skins
 
-libpthread_rt_la_LDFLAGS = -version-info 1:0:0 -lpthread
+libpthread_rt_la_LDFLAGS = @XENO_DLOPEN_CONSTRAINT@ -version-info 1:0:0 -lpthread
 
 libpthread_rt_la_SOURCES = \
 	init.c \
diff --git a/src/skins/psos+/Makefile.am b/src/skins/psos+/Makefile.am
index a579ebe..3e4464d 100644
--- a/src/skins/psos+/Makefile.am
+++ b/src/skins/psos+/Makefile.am
@@ -1,6 +1,6 @@
 lib_LTLIBRARIES = libpsos.la
 
-libpsos_la_LDFLAGS = -version-info 0:0:0 -lpthread
+libpsos_la_LDFLAGS = @XENO_DLOPEN_CONSTRAINT@ -version-info 0:0:0 -lpthread
 
 libpsos_la_SOURCES = \
 	asr.c \
diff --git a/src/skins/rtai/Makefile.am b/src/skins/rtai/Makefile.am
index 8a92859..bae83c1 100644
--- a/src/skins/rtai/Makefile.am
+++ b/src/skins/rtai/Makefile.am
@@ -1,6 +1,6 @@
 lib_LTLIBRARIES = librtai.la
 
-librtai_la_LDFLAGS = -version-info 0:0:0
+librtai_la_LDFLAGS = @XENO_DLOPEN_CONSTRAINT@ -version-info 0:0:0
 
 librtai_la_SOURCES = init.c \
 	shm.c
diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am
index 00099be..73f97cf 100644
--- a/src/skins/rtdm/Makefile.am
+++ b/src/skins/rtdm/Makefile.am
@@ -1,6 +1,6 @@
 lib_LTLIBRARIES = librtdm.la
 
-librtdm_la_LDFLAGS = -version-info 1:0:0 -lpthread
+librtdm_la_LDFLAGS = @XENO_DLOPEN_CONSTRAINT@ -version-info 1:0:0 -lpthread
 
 librtdm_la_SOURCES = \
 	core.c \
diff --git a/src/skins/uitron/Makefile.am b/src/skins/uitron/Makefile.am
index 3736a9b..a7ff65a 100644
--- a/src/skins/uitron/Makefile.am
+++ b/src/skins/uitron/Makefile.am
@@ -1,6 +1,6 @@
 lib_LTLIBRARIES = libuitron.la
 
-libuitron_la_LDFLAGS = -version-info 0:0:0 -lpthread
+libuitron_la_LDFLAGS = @XENO_DLOPEN_CONSTRAINT@ -version-info 0:0:0 -lpthread
 
 libuitron_la_SOURCES = \
 	flag.c \
diff --git a/src/skins/vrtx/Makefile.am b/src/skins/vrtx/Makefile.am
index a5517f3..6233548 100644
--- a/src/skins/vrtx/Makefile.am
+++ b/src/skins/vrtx/Makefile.am
@@ -1,6 +1,6 @@
 lib_LTLIBRARIES = libvrtx.la
 
-libvrtx_la_LDFLAGS = -version-info 0:0:0 -lpthread
+libvrtx_la_LDFLAGS = @XENO_DLOPEN_CONSTRAINT@ -version-info 0:0:0 -lpthread
 
 libvrtx_la_SOURCES = \
 	event.c \
diff --git a/src/skins/vxworks/Makefile.am b/src/skins/vxworks/Makefile.am
index 7a57055..b7b74e6 100644
--- a/src/skins/vxworks/Makefile.am
+++ b/src/skins/vxworks/Makefile.am
@@ -1,6 +1,6 @@
 lib_LTLIBRARIES = libvxworks.la
 
-libvxworks_la_LDFLAGS = -version-info 1:0:0 -lpthread
+libvxworks_la_LDFLAGS = @XENO_DLOPEN_CONSTRAINT@ -version-info 1:0:0 -lpthread
 
 libvxworks_la_SOURCES = \
 	errnoLib.c \

Re: [Xenomai-core] [PATCH v2 0/4] Various fixes and cleanups

[Jan Kiszka]

Jan Kiszka wrote:
> This is a rework/rebase of the patch series I sent last December,
> addressing the concerns and suggestions brought up during our discussion
> in January.
> 
> 
> Find the patches also at git://git.kiszka.org/xenomai.git queues/assorted
> 
> Jan Kiszka (4):
>       POSIX: Fix SCHED_RR thread creation
>       Mark libs nodlopen on initial-exec TLS
>       Add --enable-dlopen-skins configure switch
>       POSIX: Do not auto-shadow main with dlopen enabled

What is the schedule for these patches? 2..4 shouldn't be controversial
anymore (find them rebased as patch 1..3 under queues/assorted). And for
the first one I already sent a rework (now patch 4 in that queue) that
still looks fine to me. But I can also repost some/all of them if preferred.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH v2 0/4] Various fixes and cleanups

[Philippe Gerum]

Jan Kiszka wrote:
> Jan Kiszka wrote:
>> This is a rework/rebase of the patch series I sent last December,
>> addressing the concerns and suggestions brought up during our discussion
>> in January.
>>
>>
>> Find the patches also at git://git.kiszka.org/xenomai.git queues/assorted
>>
>> Jan Kiszka (4):
>>       POSIX: Fix SCHED_RR thread creation

This one needs more review and testing. It will be merged in 2.5-rc1 to get more
exposure first, before any backport to 2.4 in order to reduce the impact of any
regression we might find.

>>       Mark libs nodlopen on initial-exec TLS
>>       Add --enable-dlopen-skins configure switch
>>       POSIX: Do not auto-shadow main with dlopen enabled
> 

Will make their way to 2.4.7 and 2.5-rc1 asap.

> What is the schedule for these patches? 2..4 shouldn't be controversial
> anymore (find them rebased as patch 1..3 under queues/assorted). And for
> the first one I already sent a rework (now patch 4 in that queue) that
> still looks fine to me. But I can also repost some/all of them if preferred.
> 
> Jan
> 


-- 
Philippe.