yi li wrote:
On Wed, Feb 25, 2009 at 12:30 AM, Philippe Gerum r...@xenomai.org wrote:
2. libpthread_rt.la should not depend on lpthread.
Nak. In flat mode, turning the link dependencies order upside down will not
buy
us anything. Two-phase link is the only way to prevent circular/invalid
Jan Kiszka wrote:
Provide assert_nrt helper that checks if the caller is either not a
shadow thread or is currently running in relaxed mode. If not, SIG_XCPU
is raised.
This service is then used to provide wrappers for glibc functions that
are not realtime-safe but do not always trigger a
Jan Kiszka wrote:
As the xnsched structures get initialized later, during xnpod_init,
xnsched_cpu always returned 0 in the gatekeeper_thread prologue. That
caused binding of all gatekeepers to CPU 0.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
ksrc/nucleus/shadow.c |5 -
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
As the xnsched structures get initialized later, during xnpod_init,
xnsched_cpu always returned 0 in the gatekeeper_thread prologue. That
caused binding of all gatekeepers to CPU 0.
Signed-off-by: Jan Kiszka jan.kis
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
how much XENO_OPT_SYS_STACKPOOLSZ do I need to run switchtest for
default settings? At least on x86-64, the default 32K is not enough.
Unless we talk about GB ;), maybe it makes sense to adjust the default
size
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
how much XENO_OPT_SYS_STACKPOOLSZ do I need to run switchtest for
default settings? At least on x86-64, the default 32K is not enough.
Unless we talk about GB ;), maybe
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
how much XENO_OPT_SYS_STACKPOOLSZ do I need to run switchtest for
default settings? At least on x86-64, the default 32K
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 =
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
Paul wrote:
On Thursday 12 February 2009, Gilles Chanteperdrix wrote:
Paul wrote:
Patching a 2.6.28.2 with the relevant patch in trunk, using a config with
SMP enabled resulted in:
LD kernel/xenomai/arch/built-in.o
CC kernel/xenomai/nucleus/heap.o
In file included from
Jan Kiszka wrote:
Hi,
unfortunately I'm forced to switch to other bugs, but I found out a bit
more about the issue that pthread_getschedparam doesn't return the
correct policyprio under trunk - at least when called from threads
created via pthread_create as SCHED_FIFO:
Such threads start
Jan Kiszka wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
We should indeed postpone this just in case the upper layer indexes the
extra
state on the minor value. We can also simplify a few things doing so.
--- ksrc/nucleus/pipe.c (revision 4565)
+++ ksrc/nucleus/pipe.c (working
Philippe Gerum wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
We should indeed postpone this just in case the upper layer indexes the
extra
state on the minor value. We can also simplify a few things doing so.
--- ksrc/nucleus/pipe.c (revision 4565)
+++ ksrc/nucleus/pipe.c
Jan Kiszka wrote:
This is an attempt to fix the bugs found in the minor number management:
- changing the bitmap requires atomic operations
- clrbits/setbits work against xnarch_atomic_t, and that is only 32 bit
wide on x86-64
I think we should rather fix xnarch_atomic_t to be the size of a
Gilles Chanteperdrix wrote:
As for the find_first_bit, why not simply taking the nklock
in
xnpipe_minor_free ? This is a first masking section, so this should not
matter a lot.
a short masking section
--
Gilles
Hi,
having to work on twice consecutive FPU issues made me think a bit about
the situation of FPU support in Xenomai.
What makes our FPU support code so complex? It is the fact that we
support eager FPU context save/restore for both user-space and
kernel-space real-time threads which ask it
Paul wrote:
Hi Giles
On Tuesday 27 January 2009, Gilles Chanteperdrix wrote:
So, the question is: are there people around who either:
- need FPU support for kernel-space real-time threads;
- do not want to pay the price of a trap when using the FPU in user-space.
One application that I
Philippe Gerum wrote:
Fillod Stephane wrote:
Hi,
I haven't seen a reply to this patch, maybe it has been missed?
Actually, it was on queue but delayed by the inlined patch.
The shm_open/unlink should be fixed by now in both the v2.4.x and trunk
You mean mmap64/ftruncate64, right?
--
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
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
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
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi,
I run clocktest on a system here, not running NTP, using
CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
this happen? Does it come from the error due to the multiply
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi,
I run clocktest on a system here, not running NTP, using
CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
this happen? Does it come from
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi,
I run clocktest on a system here, not running NTP, using
CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
Hi,
I run clocktest on a system here, not running NTP, using
CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
this happen? Does it come from the error due to the multiply and shift
used for tsc to/from ns conversions ?
TIA,
--
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi,
I run clocktest on a system here, not running NTP, using
CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
this happen? Does it come from the error due to the multiply and shift
used for tsc to/from ns conversions
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi,
I run clocktest on a system here, not running NTP, using
CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can
this happen? Does it come from the error due to the multiply and shift
used for tsc to/from ns conversions
Wolfgang Grandegger wrote:
Hello,
first a Happy New Year to everybody.
With the POSIX skin of Xenomai trunk I get the following Oops when I
exit my application (with ^C) on my PowerPC :
Xenomai: fatal: removing non-linked element, holder=c78e69c8, qslot=c7b03030
at
Wolfgang Grandegger wrote:
Hello,
first a Happy New Year to everybody.
With the POSIX skin of Xenomai trunk I get the following Oops when I
exit my application (with ^C) on my PowerPC :
Xenomai: fatal: removing non-linked element, holder=c78e69c8, qslot=c7b03030
at
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Regarding this thread, I would appreciate if we could just stay on
topic. If you don't have the time for the patches, then it's absolutely
OK, just leave them alone.
I am reluctant to test patches which are explicitely labeled
Jan Kiszka wrote:
Changes since last round:
- Fix build breakage of trunk against 2.6.27
- Make rthal_nmi_release more robust (additional patch)
- Fix issue of last patch on 32 bit (untested last-minute changes...)
All patches are also available at
git://git.kiszka.org/xenomai.git
Jan Kiszka wrote:
This is basically a repost of the NNI watchdog series I sent out a few
weeks ago. I just rebased things over latest trunk and fixed some
warnings.
All patches are also available at
git://git.kiszka.org/xenomai.git nmi-wd-queue
That is a lot of stuff to review. I am afraid
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
This is basically a repost of the NNI watchdog series I sent out a few
weeks ago. I just rebased things over latest trunk and fixed some
warnings.
All patches are also available at
git://git.kiszka.org/xenomai.git nmi-wd-queue
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
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
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
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
here is a trivial test case on my desk that points to SCHED_RR issues of
the POSIX skin: simple pthread_create
Jan Kiszka wrote:
Hi Gilles,
here is a trivial test case on my desk that points to SCHED_RR issues of
the POSIX skin: simple pthread_create with an attribute block that has
SCHED_RR set, but neither SCHED_RR nor the priority reach the new thread.
The way the scheduling policy and
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
here is a trivial test case on my desk that points to SCHED_RR issues of
the POSIX skin: simple pthread_create with an attribute block that has
SCHED_RR set, but neither SCHED_RR nor the priority reach the new thread
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
here is a trivial test case on my desk that points to SCHED_RR issues of
the POSIX skin: simple pthread_create with an attribute block that has
SCHED_RR set
Jan Kiszka wrote:
Some naive optimist once claim that the dynamic linker would detect if
we try to dlopen some Xenomai lib (directly or indirectly) which uses
the optimised initial-exec TLS variables. He was wrong of course. It
takes the special marker nodlopen to achieve this, and that's what
Jan Kiszka wrote:
Hi Gilles,
I assumed you armed nodiv ns-to-tsc for x86-64, given that the services
are in place now. But my test case just crashed another box even though
latest SVN was installed. Any reason for not converting yet?
Yes, I only tested the routine performance, not tested
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
I assumed you armed nodiv ns-to-tsc for x86-64, given that the services
are in place now. But my test case just crashed another box even though
latest SVN was installed. Any reason for not converting yet?
Yes, I
Jan Kiszka wrote:
+#ifndef CONFIG_XENO_POSIX_AUTO_MLOCKALL
if (mlockall(MCL_CURRENT | MCL_FUTURE)) {
perror(Xenomai Posix skin init: mlockall);
exit(EXIT_FAILURE);
}
Errr... I do not get it, the mlockall should take place if AUTO_MLOCKALL
is set, no ?
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Author: gch
Date: Sun Nov 16 03:30:40 2008
New Revision: 4392
URL: http://svn.gna.org/viewcvs/xenomai?rev=4392view=rev
Log:
Implement nodiv_ullimd on x86_64
Modified:
trunk/include/asm-x86/arith_64.h
Nice. This solves the user
Hi Jan,
I have just commited a modification of the nucleus heap which allows
faulting newly mapped pages. However, I noticed that we should modify
rtdm_mmap_to_user as in the attached patch.
At this chance, I also noticed that there is no way to ask for uncached
memory to rtdm_mmap_to_user, how
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
I see that the implementation of rthal_llmulshft seems to account for
the first argument sign. Does it work ? Namely, in the generic
implementation will __rthal_u96shift propagate the sign
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
I see that the implementation of rthal_llmulshft seems to account for
the first argument sign. Does it work ? Namely, in the generic
implementation
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
I see that the implementation of rthal_llmulshft seems to account for
the first argument sign. Does it work ? Namely, in the generic
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
I see that the implementation of rthal_llmulshft seems to account for
the first argument sign. Does it work ? Namely, in the generic
implementation will __rthal_u96shift propagate the sign bit ?
Yes, this works (given
Matteo Facchinetti @ Sirius Electronic Systems S.R.L. wrote:
Hi all,
I'm using framework RTDM to develop my driver on embedded system mpc5200
based.
(kernel 2.6.24.4 (powerpc arch) - xenomai 2.4.3).
I've need to use rtdm_mmap_to_user() to share a kmalloc() kernel memory
in userspace.
Hi Jan,
I see that the implementation of rthal_llmulshft seems to account for
the first argument sign. Does it work ? Namely, in the generic
implementation will __rthal_u96shift propagate the sign bit ?
If yes, do you see a way llimd could be made to work the same way ? This
way we would avoid
Alexis Berlemont wrote:
Hi Gilles,
Sorry for answering so late. I was unable to regularly check my private mails
the last week; I missed yours.
I commited in trunk a fix of Xenomai heap management for the highmem
case. What the patch does is essentially replacing __va_to_kva (which
does
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Well, what about merging the solutions: trap the signal from the library
constructor by default for people relying on #1, AND document the shadow
signal
handler for people who can do #2?
For me, merging the two, would mean keep
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Well, what about merging the solutions: trap the signal from the library
constructor by default for people relying on #1, AND document the shadow
signal
handler for people who can do #2?
For me
I get this warning when compiling trunk:
checking for __thread... rm: cannot remove `conftest1.dir': Is a directory
yes
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
I get this warning when compiling trunk:
checking for __thread... rm: cannot remove `conftest1.dir': Is a directory
yes
That simple, it's a typo in this line:
http://www.rts.uni-hannover.de/xenomai/lxr/source
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
I get this warning when compiling trunk:
checking for __thread... rm: cannot remove `conftest1.dir': Is a directory
yes
That simple, it's a typo in this line:
http
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
I get this warning when compiling trunk:
checking for __thread... rm: cannot remove `conftest1.dir': Is a
directory
yes
That simple, it's
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
I get this warning when compiling trunk:
checking for __thread... rm: cannot remove `conftest1
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
I get this warning when compiling trunk
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Well I am busy with the ARM FCSE now. Do you want my test case ?
Yes, hoping that it triggers on x86 as well. And is toolchain independent.
--
Gilles.
#include stdio.h
#include sys/mman.h
#include
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Well I am busy with the ARM FCSE now. Do you want my test case ?
Yes, hoping that it triggers on x86 as well. And is toolchain independent.
It doesn't trigger. Can you reproduce on x86?
I think
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Well I am busy with the ARM FCSE now. Do you want my test case ?
Yes, hoping that it triggers on x86 as well. And is toolchain independent.
It doesn't trigger. Can you reproduce on x86?
Beware, I
Jan Kiszka wrote:
I wonder if we shouldn't switch the signal hooking strategy: So far we
install the handler at shadow thread creation time, saving a potentially
installed handler of the application for redirection of
Xenomai-unrelated events. But that only works if the application
installed
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I wonder if we shouldn't switch the signal hooking strategy: So far we
install the handler at shadow thread creation time, saving a potentially
installed handler of the application for redirection of
Xenomai-unrelated events
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Hi,
here is a patch which implements the idea discussed previously of
re-using SIGWINCH to trigger priority changes in user-space. There is
only one patch, but the files should have been put in a logical order
to make review easier
Philippe Gerum wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I wonder if we shouldn't switch the signal hooking strategy: So far we
install the handler at shadow thread creation time, saving a potentially
installed
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I wonder if we shouldn't switch the signal hooking strategy: So far we
install the handler at shadow thread creation time, saving a potentially
installed handler
Hi,
here is a patch which implements the idea discussed previously of
re-using SIGWINCH to trigger priority changes in user-space. There is
only one patch, but the files should have been put in a logical order
to make review easier.
Index: include/nucleus/thread.h
Gilles Chanteperdrix wrote:
Hi,
here is a patch which implements the idea discussed previously of
re-using SIGWINCH to trigger priority changes in user-space. There is
only one patch, but the files should have been put in a logical order
to make review easier.
Since there are chances
Jan Kiszka wrote:
PS: Hope this series is compatible with more mail clients /wrt
commenting on the inlined patches.
I tested and it is true I could reply to your patches. However, your
mailer does not put any Content-type of Content-encoding info. This may
be a problem for some.
--
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Same remark for the #ifdefs.
Yes, but most cases (maybe except for owner checking) are unavoidable
due to heavy differences. I hope that we may have only FASTXNSYCH archs
one day.
I also do not understand your modification
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Same remark for the #ifdefs.
Yes, but most cases (maybe except for owner checking) are unavoidable
due to heavy differences. I hope that we may have only FASTXNSYCH archs
one day
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Same remark for the #ifdefs.
Yes, but most cases (maybe except for owner checking) are unavoidable
due to heavy differences. I hope that we may have
Jan Kiszka wrote:
But that is what cond_wait is about: releasing the associated lock to
whoever gets it - either directly or via lock-stealing. I see no problem
here. Moreover, lockcnt is never used (and must not!) as an indication
if a lock is free. It is a pure helper for the lock owner to
Jan Kiszka wrote:
Here comes a significantly reworked patch series to improve fast mutex
support of Xenomai.
This approach now introduces a generic fast xnsynch core and converts
the existing POSIX implementation over. It also comes with a second
user, the Native skin. Additionally, it
Jan Kiszka wrote:
Hopefully the last round, addressing remarks brought up on the last
posting. The changes are:
[Patches 7-9]
- define xnsynch_owner_check as xnsynch-implementation-independent way
to check provided and current synch owner match (reduces #ifdefs)
[Patches 6 and 9]
-
Jan Kiszka wrote:
This series fixes the issues around rt_task_inquire I posted yesterday.
Additionally, it introduces an analogous services pthread_inquire_np for
the POSIX skin. That allows, among other things, to implement test cases
for the upcoming fast xnsynch/mutex patches.
Ok. Since
Jan Kiszka wrote:
Here comes a significantly reworked patch series to improve fast mutex
support of Xenomai.
This approach now introduces a generic fast xnsynch core and converts
the existing POSIX implementation over. It also comes with a second
user, the Native skin. Additionally, it
Jan Kiszka wrote:
ok for me.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
Ok.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
Ok.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
Ok.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
Ok. Though I do not see the point of the FASTSEM/FASTSYNCH rename.
FASTSEM is short, and we are not much interested in getting anything
else than semaphores faster.
--
Gilles.
___
Jan Kiszka wrote:
This patch contains too many #ifdefs.
Things like
#ifdef CONFIG_XENO_FASTSYNCH
if (xnsynch_fast_owner_check(...))
#else
if (xnsynch_owner(...) == ...)
#endif
could be replaced with only one macro xnsynch_check_owner in synch.h
that would be defined with some #ifdefs, and used
Jan Kiszka wrote:
Same remark for the #ifdefs. I also do not understand your modification
of rt_cond_wait_inner, this code is very tense; posix and native had the
same bug in this area at different times, so this change should probably
be made separately.
--
Jan Kiszka wrote:
The real downside here is a lot of #ifdef clutter. What about the idea
of defining an API to abstract the differences between
pthread_get/setspecific and __thread and have #ifdef only in one header ?
--
Gilles.
Jan Kiszka wrote:
Ok. I still liked the solution of using a piece of shared heap. This was
more general and would have allowed us to use this piece of shared heap
for future purposes.
--
Gilles.
___
Jan Kiszka wrote:
Ok.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
I do not like this patch. This sould be solved using the existing
features system. I do not want SMP to be enabled by default.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
Jan Kiszka wrote:
I start to believe we are arguing with different (miss-)use case in
mind. Mine is definitely not about helping the user to switch the
thread mode even more actively. It is about validating application
states, it is about thread state reflection without any other actions
than
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Ok. Though I do not see the point of the FASTSEM/FASTSYNCH rename.
FASTSEM is short, and we are not much interested in getting anything
else than semaphores faster.
We aren't
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi,
the documentation refers to the Native Task Status (T_*) when it comes
to documenting rt_task_info.status. That is not correct. That field
contains far more flags than T_* is describing and, even worse, comes
with two collisions: T_PRIMARY and
Jan Kiszka wrote:
Hi,
looking into the xeno_in_primary_mode thing I wondered how to make the
thread state quickly retrievable. Going via pthread_getspecific as we do
for xeno_get_current appears logical - but not optimal. Though
getspecific is optimized for speed, it remains a function
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
It will always remain orders of magnitude heavier than __thread
variables which are a) inlined and b) should only need two memory
accesses at worst. Moreover, it is clearly
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
It will always remain orders of magnitude heavier than __thread
variables which are a) inlined and b) should only need two memory
Jan Kiszka wrote:
So if I get an OK for the proposal, I'll convert the rest, too.
From my point of view, it really is a micro-optimization, which
uselessly clutters code and configure script. But I really have no
concrete objection, especially since you say that __thread is the
future, not
Jan Kiszka wrote:
Ack. There are rt_printf (rtdk) and the task-self services of vxworks,
vrtx and native skins. So if I get an OK for the proposal, I'll convert
the rest, too.
And I really do not understand how the keys can be chosen at
compilation-time, especially in the situation where
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
It will always remain orders of magnitude heavier than __thread
variables which are a) inlined and b) should only need two memory
accesses at worst. Moreover, it is clearly the future, while the
importance of pthread_getspecific
701 - 800 of 1571 matches
Mail list logo
