[Xenomai-core] [PATCH 2/6] POSIX: Fix initialization of SCHED_RR threads
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.kis...@siemens.com --- 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 mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 0/6] Various fixes and cleanups
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 mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path
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.kis...@siemens.com
---
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 */
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 5/6] Replace --without-__tread with --enable-dlopen-skins
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.kis...@siemens.com
---
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 mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 4/6] Mark libs nodlopen on initial-exec TLS
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.kis...@siemens.com --- 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 mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 6/6] POSIX: Do not auto-shadow main with dlopen enabled
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.kis...@siemens.com
---
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 mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH 1/6] Handle priority changes of SCHED_RR tasks
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.kis...@siemens.com --- 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; /* ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/6] Handle priority changes of SCHED_RR tasks
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.kis...@siemens.com --- 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path
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.kis...@siemens.com
---
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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path
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.kis...@siemens.com
---
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.kis...@siemens.com
---
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 */
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 1/6] Handle priority changes of SCHED_RR tasks
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.kis...@siemens.com --- 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path
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.kis...@siemens.com
---
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.kis...@siemens.com
---
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.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 3/6] POSIX: Optimize pthread_setschedparam fast path
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.kis...@siemens.com
---
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 mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 0/6] Various fixes and cleanups
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@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 0/6] Various fixes and cleanups
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH 0/6] Various fixes and cleanups
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
