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

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

[Jan Kiszka]

Here is a queue of patches that piled up on my side. Most have been
posted earlier already, find details in the descriptions. I have some
more that will be posted later this week.

All patches are also available at
git://git.kiszka.org/xenomai.git assorted-queue

Jan

PS: BTW, I started mirroring the Xenomai SVN on my server. So far I pull
from SVN on 1:00, 12:00 and 18:00 (CET), maybe I will subscribe some
robot to the svn-commit list later. Feel free to make use of this
service as you like. For me it is a tool to keep control over my
various patch queues, and using only git (+stg) for this simplified
things significantly.

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

[Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path

[Jan Kiszka]

Optimize __wrap_pthread_setschedparam without HAVE___THREAD for the case
that an already mapped shadow is modifying its own scheduling
parameters.

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

 src/skins/posix/thread.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
index 2ecb64f..d2839c6 100644
--- a/src/skins/posix/thread.c
+++ b/src/skins/posix/thread.c
@@ -37,11 +37,10 @@ static int linuxthreads;
 int __wrap_pthread_setschedparam(pthread_t thread,
 				 int policy, const struct sched_param *param)
 {
-	pthread_t myself = pthread_self();
 	unsigned long *mode_buf = NULL;
 	int err, promoted;
 
-	if (thread == myself) {
+	if (xeno_current != XN_NO_HANDLE && thread == pthread_self()) {
 #ifdef HAVE___THREAD
 		mode_buf = xeno_init_current_mode();
 #else /* !HAVE___THREAD */

Re: [Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Optimize __wrap_pthread_setschedparam without HAVE___THREAD for the case
> that an already mapped shadow is modifying its own scheduling
> parameters.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
> ---
> 
>  src/skins/posix/thread.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
> index 2ecb64f..d2839c6 100644
> --- a/src/skins/posix/thread.c
> +++ b/src/skins/posix/thread.c
> @@ -37,11 +37,10 @@ static int linuxthreads;
>  int __wrap_pthread_setschedparam(pthread_t thread,
>  				 int policy, const struct sched_param *param)
>  {
> -	pthread_t myself = pthread_self();
>  	unsigned long *mode_buf = NULL;
>  	int err, promoted;
>  
> -	if (thread == myself) {
> +	if (xeno_current != XN_NO_HANDLE && thread == pthread_self()) {

I was under the impression that xeno_current was only correct with
HAVE__THREAD. Otherwise, I guess we should use xeno_get_current(), no?

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Optimize __wrap_pthread_setschedparam without HAVE___THREAD for the case
>> that an already mapped shadow is modifying its own scheduling
>> parameters.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
>> ---
>>
>>  src/skins/posix/thread.c |    3 +--
>>  1 files changed, 1 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
>> index 2ecb64f..d2839c6 100644
>> --- a/src/skins/posix/thread.c
>> +++ b/src/skins/posix/thread.c
>> @@ -37,11 +37,10 @@ static int linuxthreads;
>>  int __wrap_pthread_setschedparam(pthread_t thread,
>>  				 int policy, const struct sched_param *param)
>>  {
>> -	pthread_t myself = pthread_self();
>>  	unsigned long *mode_buf = NULL;
>>  	int err, promoted;
>>  
>> -	if (thread == myself) {
>> +	if (xeno_current != XN_NO_HANDLE && thread == pthread_self()) {
> 
> I was under the impression that xeno_current was only correct with
> HAVE__THREAD. Otherwise, I guess we should use xeno_get_current(), no?
> 

Of course.

------->

Optimize __wrap_pthread_setschedparam without HAVE___THREAD for the case
that an already mapped shadow is modifying its own scheduling
parameters.

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

 src/skins/posix/thread.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
index 2ecb64f..46c49bf 100644
--- a/src/skins/posix/thread.c
+++ b/src/skins/posix/thread.c
@@ -37,11 +37,10 @@ static int linuxthreads;
 int __wrap_pthread_setschedparam(pthread_t thread,
 				 int policy, const struct sched_param *param)
 {
-	pthread_t myself = pthread_self();
 	unsigned long *mode_buf = NULL;
 	int err, promoted;
 
-	if (thread == myself) {
+	if (xeno_get_current() != XN_NO_HANDLE && thread == pthread_self()) {
 #ifdef HAVE___THREAD
 		mode_buf = xeno_init_current_mode();
 #else /* !HAVE___THREAD */

Re: [Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Optimize __wrap_pthread_setschedparam without HAVE___THREAD for the case
>>> that an already mapped shadow is modifying its own scheduling
>>> parameters.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
>>> ---
>>>
>>>  src/skins/posix/thread.c |    3 +--
>>>  1 files changed, 1 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
>>> index 2ecb64f..d2839c6 100644
>>> --- a/src/skins/posix/thread.c
>>> +++ b/src/skins/posix/thread.c
>>> @@ -37,11 +37,10 @@ static int linuxthreads;
>>>  int __wrap_pthread_setschedparam(pthread_t thread,
>>>  				 int policy, const struct sched_param *param)
>>>  {
>>> -	pthread_t myself = pthread_self();
>>>  	unsigned long *mode_buf = NULL;
>>>  	int err, promoted;
>>>  
>>> -	if (thread == myself) {
>>> +	if (xeno_current != XN_NO_HANDLE && thread == pthread_self()) {
>> I was under the impression that xeno_current was only correct with
>> HAVE__THREAD. Otherwise, I guess we should use xeno_get_current(), no?
>>
> 
> Of course.
> 
> ------->
> 
> Optimize __wrap_pthread_setschedparam without HAVE___THREAD for the case
> that an already mapped shadow is modifying its own scheduling
> parameters.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
> ---
> 
>  src/skins/posix/thread.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
> index 2ecb64f..46c49bf 100644
> --- a/src/skins/posix/thread.c
> +++ b/src/skins/posix/thread.c
> @@ -37,11 +37,10 @@ static int linuxthreads;
>  int __wrap_pthread_setschedparam(pthread_t thread,
>  				 int policy, const struct sched_param *param)
>  {
> -	pthread_t myself = pthread_self();
>  	unsigned long *mode_buf = NULL;
>  	int err, promoted;
>  
> -	if (thread == myself) {
> +	if (xeno_get_current() != XN_NO_HANDLE && thread == pthread_self()) {

Should not this be xeno_get_current() == XN_NO_HANDLE ? The thread has a
chance to be promoted only if it is not already shadowed.

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
>> index 2ecb64f..46c49bf 100644
>> --- a/src/skins/posix/thread.c
>> +++ b/src/skins/posix/thread.c
>> @@ -37,11 +37,10 @@ static int linuxthreads;
>>  int __wrap_pthread_setschedparam(pthread_t thread,
>>  				 int policy, const struct sched_param *param)
>>  {
>> -	pthread_t myself = pthread_self();
>>  	unsigned long *mode_buf = NULL;
>>  	int err, promoted;
>>  
>> -	if (thread == myself) {
>> +	if (xeno_get_current() != XN_NO_HANDLE && thread == pthread_self()) {
> 
> Should not this be xeno_get_current() == XN_NO_HANDLE ? The thread has a
> chance to be promoted only if it is not already shadowed.

Oh, hell. Friday-evening-on-the-train hack that hasn't been checked as
it was so obvious...

--------->

Optimize __wrap_pthread_setschedparam without HAVE___THREAD for the case
that an already mapped shadow is modifying its own scheduling
parameters.

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

 src/skins/posix/thread.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
index 2ecb64f..5e04082 100644
--- a/src/skins/posix/thread.c
+++ b/src/skins/posix/thread.c
@@ -37,11 +37,10 @@ static int linuxthreads;
 int __wrap_pthread_setschedparam(pthread_t thread,
 				 int policy, const struct sched_param *param)
 {
-	pthread_t myself = pthread_self();
 	unsigned long *mode_buf = NULL;
 	int err, promoted;
 
-	if (thread == myself) {
+	if (xeno_get_current() == XN_NO_HANDLE && thread == pthread_self()) {
 #ifdef HAVE___THREAD
 		mode_buf = xeno_init_current_mode();
 #else /* !HAVE___THREAD */

[Xenomai-core] [PATCH 6/6] 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 5/6] Replace --without-__tread with --enable-dlopen-skins

[Jan Kiszka]

In practice, you only want to disable __thread support when Xenomai skin
libraries should be loadable via dlopen. Therefore rename the related
configure switch accordingly.

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

 configure.in |   19 +++++++++++++------
 1 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/configure.in b/configure.in
index 6558ebf..ff6bf66 100644
--- a/configure.in
+++ b/configure.in
@@ -765,14 +765,21 @@ 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)]),
-	    [use__thread=$withval],
-	    [use__thread=yes])
+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
 
 dnl Check whether the compiler supports the __thread keyword.
-if test "x$use__thread" != xno; then
+if test "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 2/6] POSIX: Fix initialization of SCHED_RR threads

[Jan Kiszka]

Passing SCHED_RR as policy to pthread_create has currently not the
desired effect. The kernel part expects that user space adjusts the
policy and prio via __pse51_thread_setschedparam after setting up the
shadow. And this is what the patch does by calling the wrapped
pthread_setschedparam instead of the real one.

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

 src/skins/posix/thread.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
index 1544291..2ecb64f 100644
--- a/src/skins/posix/thread.c
+++ b/src/skins/posix/thread.c
@@ -162,7 +162,7 @@ static void *__pthread_trampoline(void *arg)
 		/* 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);
+		__wrap_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

[Xenomai-core] [PATCH 4/6] 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 0a03057..6558ebf 100644
--- a/configure.in
+++ b/configure.in
@@ -764,6 +764,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)]),
@@ -784,6 +785,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
 
@@ -805,6 +807,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 \

[Xenomai-core] [PATCH 1/6] Handle priority changes of SCHED_RR tasks

[Jan Kiszka]

If shadowed Linux tasks with SCHED_RR policy change their priority,
do_setsched_event currenty ignores this. Extend the condition to catch
this case as well.

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

 ksrc/nucleus/shadow.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index bd3bb3d..9f81c32 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -2312,7 +2312,7 @@ static inline void do_setsched_event(struct task_struct *p, int priority)
 	union xnsched_policy_param param;
 	struct xnsched *sched;
 
-	if (!thread || p->policy != SCHED_FIFO)
+	if (!thread || (p->policy != SCHED_FIFO && p->policy != SCHED_RR))
 		return;
 
 	/*

Re: [Xenomai-core] [PATCH 1/6] Handle priority changes of SCHED_RR tasks

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> If shadowed Linux tasks with SCHED_RR policy change their priority,
> do_setsched_event currenty ignores this. Extend the condition to catch
> this case as well.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
> ---
> 
>  ksrc/nucleus/shadow.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
> index bd3bb3d..9f81c32 100644
> --- a/ksrc/nucleus/shadow.c
> +++ b/ksrc/nucleus/shadow.c
> @@ -2312,7 +2312,7 @@ static inline void do_setsched_event(struct task_struct *p, int priority)
>  	union xnsched_policy_param param;
>  	struct xnsched *sched;
>  
> -	if (!thread || p->policy != SCHED_FIFO)
> +	if (!thread || (p->policy != SCHED_FIFO && p->policy != SCHED_RR))
>  		return;

After some thinking about it, I think this is the wrong way to go. When
the user-space requests SCHED_RR, only the shadow should use SCHED_RR,
the linux thread should keep using SCHED_FIFO. We do not want two
schedulers to do round-robin, this would result in unpredictable behaviour.

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH 1/6] Handle priority changes of SCHED_RR tasks

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> If shadowed Linux tasks with SCHED_RR policy change their priority,
>> do_setsched_event currenty ignores this. Extend the condition to catch
>> this case as well.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
>> ---
>>
>>  ksrc/nucleus/shadow.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>> index bd3bb3d..9f81c32 100644
>> --- a/ksrc/nucleus/shadow.c
>> +++ b/ksrc/nucleus/shadow.c
>> @@ -2312,7 +2312,7 @@ static inline void do_setsched_event(struct task_struct *p, int priority)
>>  	union xnsched_policy_param param;
>>  	struct xnsched *sched;
>>  
>> -	if (!thread || p->policy != SCHED_FIFO)
>> +	if (!thread || (p->policy != SCHED_FIFO && p->policy != SCHED_RR))
>>  		return;
> 
> After some thinking about it, I think this is the wrong way to go. When
> the user-space requests SCHED_RR, only the shadow should use SCHED_RR,
> the linux thread should keep using SCHED_FIFO. We do not want two
> schedulers to do round-robin, this would result in unpredictable behaviour.

Well, passing SCHED_FIFO instead of SCHED_RR to glibc is one thing. But
as you can't enforce this mapping anyway, I don't think it is wrong to
accept also prio changes of SCHED_RR shadow threads.

Jan

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

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

[Philippe Gerum]

Jan Kiszka wrote:
> Here is a queue of patches that piled up on my side. Most have been
> posted earlier already, find details in the descriptions. I have some
> more that will be posted later this week.
> 
> All patches are also available at
> git://git.kiszka.org/xenomai.git assorted-queue
> 
> Jan
> 
> PS: BTW, I started mirroring the Xenomai SVN on my server. So far I pull
> from SVN on 1:00, 12:00 and 18:00 (CET), maybe I will subscribe some
> robot to the svn-commit list later. Feel free to make use of this
> service as you like. For me it is a tool to keep control over my
> various patch queues, and using only git (+stg) for this simplified
> things significantly.
>

I'm git-based on my side as well. At some point we should get rid of SVN altogether.

> --
> Siemens AG, Corporate Technology, CT SE 26
> Corporate Competence Center Embedded Linux
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 
Philippe.

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

[Jan Kiszka]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Here is a queue of patches that piled up on my side. Most have been
>> posted earlier already, find details in the descriptions. I have some
>> more that will be posted later this week.
>>
>> All patches are also available at
>> git://git.kiszka.org/xenomai.git assorted-queue
>>
>> Jan
>>
>> PS: BTW, I started mirroring the Xenomai SVN on my server. So far I pull
>> from SVN on 1:00, 12:00 and 18:00 (CET), maybe I will subscribe some
>> robot to the svn-commit list later. Feel free to make use of this
>> service as you like. For me it is a tool to keep control over my
>> various patch queues, and using only git (+stg) for this simplified
>> things significantly.
>>
> 
> I'm git-based on my side as well. At some point we should get rid of SVN altogether.
> 

That would be great. As I don't feel brave enough for a "git svn
dcommit" from my cloned tree, I still have to apply patches on a real
SVN repository whenever I have to commit on my own.

Once we switched to git, please also let us discuss how to deal with
ChangeLog in the future. Describing modifications twice or more is not
very efficient (nor motivating for a lazy developer). If we want some
high-level description in that file, then let's define what to be logged
there, and how. Its current level of details appears to be overkill
IMHO. I would prefer to focus on more verbose git commit logs.

Jan

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

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

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>> Here is a queue of patches that piled up on my side. Most have been
>>> posted earlier already, find details in the descriptions. I have some
>>> more that will be posted later this week.
>>>
>>> All patches are also available at
>>> git://git.kiszka.org/xenomai.git assorted-queue
>>>
>>> Jan
>>>
>>> PS: BTW, I started mirroring the Xenomai SVN on my server. So far I pull
>>> from SVN on 1:00, 12:00 and 18:00 (CET), maybe I will subscribe some
>>> robot to the svn-commit list later. Feel free to make use of this
>>> service as you like. For me it is a tool to keep control over my
>>> various patch queues, and using only git (+stg) for this simplified
>>> things significantly.
>>>
>> I'm git-based on my side as well. At some point we should get rid of SVN altogether.
>>
> 
> That would be great. As I don't feel brave enough for a "git svn
> dcommit" from my cloned tree, I still have to apply patches on a real
> SVN repository whenever I have to commit on my own.
>

100% same case here...

> Once we switched to git, please also let us discuss how to deal with
> ChangeLog in the future. Describing modifications twice or more is not
> very efficient (nor motivating for a lazy developer). If we want some
> high-level description in that file, then let's define what to be logged
> there, and how. Its current level of details appears to be overkill
> IMHO.

YMMV, it saved my day a few times when bisecting. It should document changes
that affect previous assumptions on the way the damn thing used to work and does
not anymore, and/or create/remove side-effects, and/or update some interface,
and/or fix the core logic in a way or another. This is not to say that it
actually always does that though.

 I would prefer to focus on more verbose git commit logs.
> 

ChangeLog would disappear completely in favor of more detailed git logs. There
is indeed no point in duplicating information.

> Jan
> 


-- 
Philippe.