Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Hi,
>>>
>>> currently I have the following six patches in my assorted queue
>>> (git://git.kiszka.org/xenomai.git queue/assorted). All have been posted
>>> before, I just rebased them since then a few times. Should I repost
>>> any/all of them (would be no problem), or are some already queued for
>>> potential merge?
>>>
>>> Jan
>>>
>>> (...)
>>> commit a631ab2c531d5e381ba8a0a59bf301a0276d9f99
>>> Author: Jan Kiszka <jan.kis...@siemens.com>
>>> Date:   Thu Jan 15 11:10:24 2009 +0100
>>>
>>>     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(-)
>>>
>>> commit 91ae3da822ca558804bf33be4d164ea4c2667c1b
>>> Author: Jan Kiszka <jan.kis...@siemens.com>
>>> Date:   Thu Jan 15 11:10:24 2009 +0100
>>>
>>>     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>
>>>
>> Nack these two ones: one of the gcc bugs I have found on ARM is related
>> to __thread (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38815). So,
>> even though I have found a work around for the bug, I am not sure that
>> it works all the time, so disabling __thread on ARM is safer. Especially
>> since __thread does not bring any performance improvement over
>> pthread_(get|set)specific on ARM.
>>
>>> commit 028d4766a38b6937d9a2c02a20022e3ee5b67b55
>>> Author: Jan Kiszka <jan.kis...@siemens.com>
>>> Date:   Thu Jan 15 11:10:24 2009 +0100
>>>
>>>     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(-)
>>>
>>> commit 71666ce04ef216d281fe86ee82a5560c2b57c6dd
>>> Author: Jan Kiszka <jan.kis...@siemens.com>
>>> Date:   Thu Jan 15 11:10:24 2009 +0100
>>>
>>>     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(-)
>>>
>> Nack these two ones too. Philippe implemented a SCHED_RR working over
>> aperiodic mode. I think the POSIX skin needs fixing, but not that way.
> 
> Then please suggest a better fix.

I thought I did: simply pass the SCHED_RR option to kernel-space and
handle it there, but replace it with SCHED_FIFO for anything in
user-space. I plan to do it, but trunk is not my current priority.

> 
>> We should have the thread run with SCHED_FIFO in secondary mode even if
>> it runs under round-robin in primary mode.
> 
> As I explained, that can always be a weak policy. No one can prevent the
> user from setting his Linux thread to SCHED_RR.
> 
>> And when we have done that,
>> we do not need the second patch, since a shadow linux task will always
>> run with SCHED_FIFO.
>>
> 
> Only by convention, not by feasible design (unless you want to change
> the kernel in this respect).

I think the sane usage of Xenomai is to rely on Xenomai services, not to
use __real_pthread_setschedparam to set the Linux side priority of a
real-time thread.

-- 
                                                 Gilles.

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to