Jan Kiszka wrote:
+#include asm/atomic.h
+
+#if BITS_PER_LONG != 32
+#error Upgrade to kernel 2.6!
+#endif
I am not well versed with the 2.4 support. But are we sure we support no
64 bits architecture with 2.4 ? What about ppc64 ?
--
Gilles.
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
+#include asm/atomic.h
+
+#if BITS_PER_LONG != 32
+#error Upgrade to kernel 2.6!
+#endif
I am not well versed with the 2.4 support. But are we sure we support no
64 bits architecture with 2.4 ? What about ppc64 ?
AFAIK
Jan Kiszka wrote:
Hi,
what is the policy for the user space handles the native skin generates:
Can the user share them between processes via putting them into shared
memory (like it is allowed for some POSIX objects)?
I'm wondering if I have to use the POSIX pattern to resolve the address
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi,
what is the policy for the user space handles the native skin generates:
Can the user share them between processes via putting them into shared
memory (like it is allowed for some POSIX objects)?
I'm wondering if I have
Hi Jan,
Please do not use my address at gmail, gna does not want me to post from
this address:
2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org
Xenomai-core@gna.org
R=dnslookup T=remote_smtp: SMTP error from remote mailer after RCPT
TO:Xenomai-
[EMAIL PROTECTED]: host
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
...and also automatically fixes the missing LOCK prefix for
pthread_mutex_* services on x86_32 SMP.
This looks to me as a half-way unification. Can we not totally get rid
of atomic_32.h and atomic_64.h ? I mean since we
Gilles Chanteperdrix wrote:
Hi Jan,
Please do not use my address at gmail, gna does not want me to post from
this address:
2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org
Xenomai-core@gna.org
R=dnslookup T=remote_smtp: SMTP error from remote mailer after RCPT
TO:Xenomai
Jan Kiszka wrote:
Hi Gilles,
trying to understand the cb_read/write lock usage, some question came up
here: What prevents that the mutexq iteration in pse51_mutex_check_init
races against pse51_mutex_destroy_internal?
If nothing, then I wonder if we actually have to iterate over the whole
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
trying to understand the cb_read/write lock usage, some question came up
here: What prevents that the mutexq iteration in pse51_mutex_check_init
races against pse51_mutex_destroy_internal?
If nothing, then I wonder
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
trying to understand the cb_read/write lock usage, some question came up
here: What prevents that the mutexq iteration in pse51_mutex_check_init
races against pse51_mutex_destroy_internal
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
Please do not use my address at gmail, gna does not want me to post from
this address:
2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org
Xenomai-core@gna.org
R=dnslookup T=remote_smtp: SMTP error from remote mailer
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
trying to understand the cb_read/write lock usage, some question came up
here: What prevents that the mutexq iteration
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
Please do not use my address at gmail, gna does not want me to post from
this address:
2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org
Xenomai-core@gna.org
R
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
Please do not use my address at gmail, gna does not want me to post from
this address:
2008-08-23 12:10:19 1KWq4T-zD-9E ** xenomai-core@gna.org
Xenomai-core@gna.org
R=dnslookup T
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
decision (we could store the first pending thread priority in a
user/kernel shared area, with the complication that we would need
updating this priority if it ever changes, but to get the priority of
the current thread, we also need a syscall
Jan Kiszka wrote:
Disabling SMP (on platforms where this isn't off by design already) is
an optimization. In contrast, not enabling it by default is doomed to
cause problems for users that run ./configure without looking into each
and every switch - now that CONFIG_SMP is very important for
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Disabling SMP (on platforms where this isn't off by design already) is
an optimization. In contrast, not enabling it by default is doomed to
cause problems for users that run
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Disabling SMP (on platforms where this isn't off by design already) is
an optimization. In contrast, not enabling it by default
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:
Disabling SMP (on platforms where
Jan Kiszka wrote:
As the subject says. Passed your unit_mutex test, nothing else tried
yet, weekend is calling.
Ok for me.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
Jan Kiszka wrote:
...and also automatically fixes the missing LOCK prefix for
pthread_mutex_* services on x86_32 SMP.
This looks to me as a half-way unification. Can we not totally get rid
of atomic_32.h and atomic_64.h ? I mean since we are using unsigned long
as atomic_t on both platforms,
Jan Kiszka wrote:
Hi Gilles,
do you - or anyone else - happen to have some patches under preparation
to extend also the native skin with the newly added CONFIG_XENO_FASTSEM
support? Just to avoid duplicate work (we are about to work on this).
Not yet. But the fastsem work is largely
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
do you - or anyone else - happen to have some patches under preparation
to extend also the native skin with the newly added CONFIG_XENO_FASTSEM
support? Just to avoid duplicate work (we are about to work on this).
Not yet
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
do you - or anyone else - happen to have some patches under preparation
to extend also the native skin with the newly added CONFIG_XENO_FASTSEM
support? Just to avoid duplicate work (we
Jan Kiszka wrote:
+ /* We are awake, no one must steal our lock anymore. */
+ thread-wwake = NULL;
+
This is wrong, whether or not no one must steal our lock anymore will be
decided at the redo label, when we test and set, the synch owner.
--
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
+/* We are awake, no one must steal our lock anymore. */
+thread-wwake = NULL;
+
This is wrong, whether or not no one must steal our lock anymore will be
decided at the redo label, when we test and set, the synch owner.
Ok
Philippe Gerum wrote:
-head = snprintf(name, XNOBJECT_NAME_LEN, IRQ%d: , irq);
-name += head;
-strncpy(name, intr-name, XNOBJECT_NAME_LEN-head);
+head = snprintf(name_buf, XNOBJECT_NAME_LEN, IRQ%d: , irq);
+strncpy(name_buf + head, intr-name, XNOBJECT_NAME_LEN-head);
-
Fillod Stephane wrote:
Jan Kiszka wrote:
/proc/xenomai/stat output is strange. Probably some type cast error,
because 18446744071739514846 = 0x8A939FDE and the appropriate
value perhaps should be 0x8A939FDE = 2324930526.
[...]
Reminds me that other pending patch for
Ulrich Schwab wrote:
On Tue, Jul 29, 2008 at 4:20 PM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Ulrich Schwab wrote:
why not checking for irq origin like this:
int my_isr_handler (xnintr_t *irq)
{
if ( ! test_my_card_for_irq_origin )
return XN_ISR_NONE
Gilles Chanteperdrix wrote:
Ulrich Schwab wrote:
why not checking for irq origin like this:
int my_isr_handler (xnintr_t *irq)
{
if ( ! test_my_card_for_irq_origin )
return XN_ISR_NONE | XN_ISR_PROPAGATE;
... /* handling */
return XN_ISR_HANDLED;
}
this way XN_ISR_PROPAGATE
Ulrich Schwab wrote:
On Tue, Jul 29, 2008 at 4:20 PM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Ulrich Schwab wrote:
why not checking for irq origin like this:
int my_isr_handler (xnintr_t *irq)
{
if ( ! test_my_card_for_irq_origin )
return XN_ISR_NONE
Ulrich Schwab wrote:
why not checking for irq origin like this:
int my_isr_handler (xnintr_t *irq)
{
if ( ! test_my_card_for_irq_origin )
return XN_ISR_NONE | XN_ISR_PROPAGATE;
... /* handling */
return XN_ISR_HANDLED;
}
this way XN_ISR_PROPAGATE is never returned in the
Gilles Chanteperdrix wrote:
Another possibility would be to use snprintf instead of strncpy in
xnobject_copy_name, and use xnobject_copy_name here.
Yet another possibility would be to use strlcpy, available in
kernel-space. But it is funny, glibc people does not seem to like
strlcpy
Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner is actually a native
task. Therefore this patch
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
This can be helpful for debugging the (futile) release attempts of
mutexes by tasks that do not own them.
Returning the RT_TASK reference may appear more consistent on first
sight, but it cannot be guaranteed that the owner
Roland Stigge wrote:
Roland Stigge wrote:
By the way: lintian(1) detects several empty *.map files which weren't
empty in 2.4.3.
i.e.
arm_2hal_8c__incl.map
blackfin_2hal_8c__incl.map
blackfin_2nmi_8c__incl.map
generic_2hal_8c__incl.map
generic_2nmi_8c__incl.map
Philippe Gerum wrote:
Here is the fourth maintenance release for the v2.4.x branch. Short
log follows:
[nucleus]
* Prevent drifts between large calculated versus measured dates.
* Fix potential deadlock on SMP when ptracing shadow threads.
* Thaw timers
On Wed, Jun 4, 2008 at 5:09 PM, Markus Osterried
[EMAIL PROTECTED] wrote:
Hi,
our kernel (along with the device drivers) is specifically adapted to
our embedded system, it would be a huge bunch of work to change the
kernel.
I think to do the ipipe backport is a lot easier.
I do not have
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Hi Jan,
when compiling xenomai v2.4.x for ARM with gcc 4.2.1, I get plenty of
warnings like:
xenomai-arm/kernel/xenomai/skins/posix/syscall.c:38
On Tue, May 27, 2008 at 11:00 AM, Roland Stigge [EMAIL PROTECTED] wrote:
Hi,
Gilles Chanteperdrix wrote:
the way Debian maintained a patch to the ssh package is the
reason why a bug could remain unnoticed during two years in Debian
distributions, including so-called stable distributions. So
On Tue, May 27, 2008 at 3:19 PM, Roland Stigge [EMAIL PROTECTED] wrote:
Hi,
Gilles Chanteperdrix wrote:
What I criticize is patching without submitting patches upstream, or
without consulting upstream package maintainers, or making debian
patches hard to apply upstream.
I both submitted
Sebastian Smolorz wrote:
Hi,
rt_pipe_receive() doesn't return -EIDRM any more. The patches for trunk
and v2.4.x correct the API documentation in this regard.
Both applied, thanks.
--
Gilles.
___
Roland Stigge wrote:
Hi,
Gilles Chanteperdrix wrote:
Shipping the xenomai tarball with the debian directory has a real added
value: it allows people to build debian package without anything else,
this is an unofficial package, of course, but it can be built before the
Debian
On Mon, May 26, 2008 at 5:44 PM, Sebastian Smolorz
[EMAIL PROTECTED] wrote:
Hello Gilles,
with your last commit:
Fix compilation with ucLibc
I cannot build xenomai userland any more (at least when taking glibc).
cyclictest fails with the following error:
Roland Stigge wrote:
Hi,
Jan Kiszka wrote:
While nitpicking can sometimes be useful, though...
Thanks for the comments, I'm attaching the patch that integrates the
updated version of the man pages (incl. Makefile.am).
Applied, thanks.
--
Roland Stigge wrote:
[Warning: First in a series of several issues applicable to
xenomai.org's code.]
Hi,
at http://packages.qa.debian.org/x/xenomai.html, you can find the latest
version of Debian's package xenomai. The diff to xenomai 2.4.3
applies to the normal Xenomai
Wolfgang Grandegger wrote:
Hello,
the patch below fixes some issues with cross compiling the
DENX linuxppc_2_4_devel tree (2.4.25) for the MPC5200. I
think they are present on Xenomai trunk as well (and even
a few more).
Applied, thanks.
--
Roland Stigge wrote:
Hi Gilles,
thanks for your response. ;-)))
Gilles Chanteperdrix wrote:
I am trying to merge the debian changes back into Xenomai, however, I
have two problems:
- I can not find back the 2.4.3-4 patch, I only find 2.4.3-7;
No problem - always just take
On Wed, May 21, 2008 at 8:48 AM, Yasser Kashfi [EMAIL PROTECTED] wrote:
Hi
I try to install xemomai-2.3.5 with kernel 2.6.20.21,
after compile the kernel and reboot, I see the
following line:
ATA: abnormal status 0x7F on port 0xE507
I previously worked with older xenomai on kernel
2.6.17
On Tue, May 20, 2008 at 9:07 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote
On Mon, May 19, 2008 at 2:56 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
As far as I understood, the user-space atomic operations, used to
acquire a free mutex in user-space, are not part of the futex API
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Since binding of the semaphore heaps is now made
Gilles Chanteperdrix wrote:
On Mon, May 19, 2008 at 2:56 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
As far as I understood, the user-space atomic operations, used to
acquire a free mutex in user
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Since binding of the semaphore heaps is now made by xeno_skin_bind, there
is
much less modifications in src/skins/posix/init.c. However, I had to do
something really ugly: since binding the semaphore heaps by xeno_skin_bind
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The two syscalls defined in the posix skin now moved to the sys skin, they
are
used in user-space by include/asm-generic/bits/bind.h and the new header
include/asm-generic/bits/current.h. The global and process-specific shared
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Since binding of the semaphore heaps is now made by xeno_skin_bind,
there is
much less modifications in src/skins/posix/init.c. However, I had to
do
something really
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The two syscalls defined in the posix skin now moved to the sys skin, they
are
used in user-space by include/asm-generic/bits/bind.h and the new header
include/asm-generic/bits/current.h. The global and process-specific shared
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
The two syscalls defined in the posix skin now moved to the sys skin,
they are
used in user-space by include/asm-generic/bits/bind.h and the new
header
include
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
As far as I understood, the user-space atomic operations, used to
acquire a free mutex in user-space, are not part of the futex API. In
our case, we are using xnarch_atomic_* operations to implement portably
this user-space locking
On Tue, May 13, 2008 at 11:10 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
@@ -1236,6 +1236,9 @@ void xnpod_delete_thread(xnthread_t *thr
xnthread_cleanup_tcb(thread
On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
@@ -1236,6 +1236,9 @@ void xnpod_delete_thread(xnthread_t *thr
xnthread_cleanup_tcb(thread);
xnarch_finalize_no_switch(xnthread_archtcb(thread));
+
+ if
On Tue, May 13, 2008 at 11:32 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 11:10 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Tue, May 13, 2008 at 10:26 AM, Jan Kiszka [EMAIL PROTECTED
On Tue, May 13, 2008 at 12:46 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
No, it is supposed to work. The sched-zombie points to this zombie,
which is finalized in xnpod_finish_unlocked_switch
OK. However, I would still prefer to get xnfreesync out
On Fri, May 9, 2008 at 11:29 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
+ if (xnthread_test_info(thread, XNDEBUG))
+ unlock_timers();
+
Will this work if several threads are currently being debugged ?
--
Gilles
___
Xenomai-core
On Fri, May 9, 2008 at 12:06 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, May 9, 2008 at 11:44 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
I expressed my skepticism about this global timer freeze before :-, and
Just try debugging periodic
On Tue, May 6, 2008 at 10:11 AM, Benjamin ZORES
[EMAIL PROTECTED] wrote:
Hi,
I'm currently running an x86_32 SMP system and facing some issues with
periodic tasks.
I'd like to get a bit more information on a few assumptions I've made.
Quick sum-up of my setup:
-
On Tue, May 6, 2008 at 11:27 AM, Benjamin ZORES
[EMAIL PROTECTED] wrote:
Gilles Chanteperdrix a écrit :
On Tue, May 6, 2008 at 10:11 AM, Benjamin ZORES
[EMAIL PROTECTED] wrote:
Why not x86_64 ?
Cause I don't need 64 bits.
Have you run the latency test to know if you
On Mon, May 5, 2008 at 6:08 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
do_schedule_event() is the culprit when it reads the pending signals on the
shared queue (XNDEBUG check for rearming the timers),
A stupid suggestion: if we know that the spinlock is always locked
when calling
On Sat, May 3, 2008 at 12:34 AM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
The include/asm-arm/atomic.h header now defines the xnarch_memory_barrier in
addition to user-space atomic operations. The pxa3xx deserves a special
treatment since it uses the ARMv6 memory barrier operation
On Mon, May 5, 2008 at 6:39 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Sat, May 3, 2008 at 12:34 AM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
The include/asm-arm/atomic.h header now defines the
xnarch_memory_barrier in
addition to user-space
No comment.
---
include/posix/pthread.h| 56
ksrc/skins/posix/cb_lock.h | 84
ksrc/skins/posix/cond.c| 41 -
ksrc/skins/posix/mutex.c | 308 +++--
ksrc/skins/posix/mutex.h | 125 ++
Since binding of the semaphore heaps is now made by xeno_skin_bind, there is
much less modifications in src/skins/posix/init.c. However, I had to do
something really ugly: since binding the semaphore heaps by xeno_skin_bind
requires calls to open, ioctl, mmap, close and munmap, I redefined these
No comment.
---
asm-arm/hal.h|7 ++-
asm-generic/system.h |6 ++
2 files changed, 12 insertions(+), 1 deletion(-)
Index: include/asm-generic/system.h
===
--- include/asm-generic/system.h(revision
Hi,
here comes a second attempt of implementing user-space mutexes for the posix
skin.
Only differences with the first implementation are explained in the following
mails.
Thanks in advance for your review.
--
Gilles.
In addition to support for non cached memory mappings, this patch implements
xnheap_init_mapped and xnheap_destroy_mapped in the !CONFIG_XENO_OPT_PERVASIVE
case. This avoids a lot of #ifdefs for users of these functions without
user-space support (posix skin shared memories, and the new semaphore
The include/asm-arm/atomic.h header now defines the xnarch_memory_barrier in
addition to user-space atomic operations. The pxa3xx deserves a special
treatment since it uses the ARMv6 memory barrier operation whereas being an
ARMv5 for other operations, hence a special --enable-arm-mach=pxa3xx
On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
This patch implements the _read, _set, and _cmpxchg operations on
atomic_long_t
and atomic_ptr_t in user-space in include/asm-generic/atomic.h which
should be
included at the end
On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
This patch implements the _read, _set, and _cmpxchg operations on
atomic_long_t
On Fri, Apr 25, 2008 at 3:44 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 2:59 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Hi,
trunk check-in #3369 did not just remove some questionable critical
sections, it also happen to fix two ugly
On Fri, Apr 25, 2008 at 4:01 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 9:48 AM, Philippe Gerum [EMAIL PROTECTED]
wrote
Philippe Gerum wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 4:01 PM, Philippe Gerum [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25, 2008 at 3:42 PM, Philippe Gerum [EMAIL PROTECTED]
wrote:
Gilles Chanteperdrix wrote:
On Fri, Apr 25
Hi,
the patch series to come for review adds support for user-space mutexes to the
posix skin. Since I wanted this support to be available on my AT91RM9200, the
patch series start with patches which are mainly for the ARM architecture, to
end with reimplementation of the kernel-space and
This patch defines the macro XNARCH_SHARED_HEAP_FLAGS to be set to
XNHEAP_GFP_NONCACHED on ARM with VIVT cache. I assumed that ARM with VIPT cache
would not need non-cached mappings when sharing memory between kernel and
user-space. Please correct me if I am wrong.
---
asm-arm/hal.h|
This patch implements the _read, _set, and _cmpxchg operations on atomic_long_t
and atomic_ptr_t in user-space in include/asm-generic/atomic.h which should be
included at the end of include/asm-*/atomic.h after the definition of the same
operations for the atomic_t type and atomic64_t type on 64
This patch implements the _read, _set, and _cmpxchg operations on the atomic_t
type in user-space for ARM, using ldrex/strex on ARM v6, and the Linux kernel
helper kuser_cmpxchg on ARM pre-v6 (so, without syscalls) without SMP. Only the
SMP case for pre-v6 ARMs still use syscalls, but this case
This patch defines the new syscalls get_heap_addr (more on this syscall later),
and get_thread_cb. The get_thread_cb syscall is used in user-space to associate
the thread xnthread_t pointer with each user-space xenomai thread, using POSIX
TSD.
This is needed for the mutex implementation to allow
This patch removes much of the #ifdefery that was in ksrc/skins/posix/shm.c. It
also initializes a global shared heap (for process-shared objects), as well as a
per-process shared heap. These two heaps are mapped in the posix skin library
initialization, using the new get_heap_addr syscall to get
This patch adds architecture independent support for non cached memory
mappings. This is necessary on ARM architecture with VIVT cache to share a
mapping between kernel and user-space, but may be used in other situations (who
knows).
---
include/asm-generic/wrappers.h | 12
This patch adds the file ksrc/skins/posix/cb_lock.h, a header used in kernel and
user-space to protect access to mutex control blocks. It implements a kind of
read-write lock without rescheduling, a failure meaning a programming error.
pthread_mutex_lock and pthread_mutex_unlock are considered
The new implementation. In user-space, without syscall in the common case when a
mutex is free when locking it, and was not claimed when unlocking it.
Note that this change entails a change in behaviour of the mutexes: before this
change locking a mutex caused the calling thread to switch to
The new implementation of mutexes consists of an atomic_cmpxchg on the mutex
owner, using the classical test and set raises problems for doing this and
setting the mutex owner atomically, so we do it all at once.
The room for storing the mutex owner is allocated in a shared heap, so that it
can
On Thu, Apr 24, 2008 at 9:09 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Hi,
the patch series to come for review adds support for user-space mutexes to
the
posix skin. Since I wanted this support to be available on my AT91RM9200,
the
patch series start
On Thu, Apr 24, 2008 at 9:37 AM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
On Thu, Apr 24, 2008 at 9:09 AM, Jan Kiszka [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Hi,
the patch series to come for review adds support for user-space mutexes
to the
posix skin
On Thu, Apr 24, 2008 at 2:01 PM, Fillod Stephane
[EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
This patch adds architecture independent support for non cached memory
mappings. This is necessary on ARM architecture with VIVT cache to
share a
mapping between kernel and user-space
On Thu, Apr 24, 2008 at 3:47 PM, Fillod Stephane
[EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
PS: any plan on a H_HUGETLB one of those days?
What would this do ?
Some embedded platforms have small TLB compared to the vm hungriness of
certain real-time tasks. H_HUGETLB would
Philippe Gerum wrote:
Roland Stigge wrote:
Hi,
Roland Stigge wrote:
=
W: libxenomai-dev: symlink-is-self-recursive
usr/include/xenomai/asm-generic/xenomai .
N:
N: The symbolic link is recursive to
Roland Stigge wrote:
[Warning: First in a series of several issues applicable to
xenomai.org's code.]
Hi,
at http://packages.qa.debian.org/x/xenomai.html, you can find the latest
version of Debian's package xenomai. The diff to xenomai 2.4.3
applies to the normal Xenomai
Roland Stigge wrote:
Hi,
for the creation of the run script for klatency, I propose the attached
change to make it a proper executable (script).
Thanks for considering,
Applied, thanks.
--
Gilles.
On Thu, Apr 17, 2008 at 11:15 AM, Josh Zhao [EMAIL PROTECTED] wrote:
Hi ,
After reading Xenomai code, I have some questions:
This is the wrong list to ask them. This answer is the last I will
make to you on this list for Xenomai questions.
1.usespace-- rt_task_create
Josh Zhao wrote:
Hi all,
I know Xenomai has integrated IPC, but is it suitable for linux
task?
There are two answers:
- you can use Xenomai native skin rt pipes, they allow communication
between real-time and non real-time tasks;
- you can make your linux task a Xenomai task with
901 - 1000 of 1571 matches
Mail list logo
