Gilles Chanteperdrix wrote:
the hostrt stuff did not compile on ARM, at this chance, I had a look
and found a few things which I did not like:
- the kernel-space and user-space did not use seqcount implementations
from the same header, and what is more, seqcount is not available on 2.4
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
the hostrt stuff did not compile on ARM, at this chance, I had a look
and found a few things which I did not like:
- the kernel-space and user-space did not use seqcount implementations
from the same header
Gilles Chanteperdrix wrote:
Hi,
you will find Xenomai 2.5.4, aka Sleep Walk, at the usual place:
http://download.gna.org/xenomai/stable/xenomai-2.5.4.tar.bz2
It contains the usual amount of bug fixes and I-pipe patches update, as
well as a new piece of nice code: the so-called mayday
From: Wolfgang Mauerer (none) wolfg...@dirichlet
We can do this since the data are on the shared semaphore heap.
The basis data structure is placed so that it is accessible from
both the Linux kernel and Xenomai kernel/userland. This also
requires to make the structure work with both kernel
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
src/testsuite/unit/check-vdso.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/testsuite/unit/check-vdso.c b/src/testsuite/unit/check-vdso.c
index
into Xenomai. The data exchange
is designed to allow for lockless reading from userland.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/posix/time.h |7
ksrc/skins/posix/clock.c | 86
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-x86/atomic.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86/atomic.h b/include/asm-x86/atomic.h
index bb3ce46..16bc990 100644
(This is the Xenomai part of the mechanism, please see the ipipe
mailing list for the patches that provide the required basis
infrastructure)
This patch series extends Xenomai with a new clock, CLOCK_HOST_REALTIME.
It allows for sharing NTP-corrected real time timestamps between
Linux/ipipe
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
src/testsuite/clocktest/clocktest.c | 64 ---
1 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/src/testsuite/clocktest/clocktest.c
b
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
---
src/testsuite/clocktest/clocktest.c | 292 +-
1 files changed, 146 insertions(+), 146 deletions(-)
diff --git a/src/testsuite/clocktest/clocktest.c
b/src/testsuite/clocktest/clocktest.c
index
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
This update_vsyscall code would call ipipe_dispatch_event to pass the
data to Xenomai.
okay. That seems to have dropped from my radar, as I don't recall having
any issues
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Wall time management is typically assisted by the NTP
protocol in the Linux context, but this information is
not propagated to Xenomai. This patch adds support
for a CLOCK_HOST_REALTIME clock id that is coupled to the
host operating
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Some points that may require further discussion:
- POSIX only specifies a few clock_ids, and these have already been
extended by the Linux kernel. We use the maximum id (16) for the new
clock, but it might also make sense to use 7
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Augment the shared vdso page with all data required to
implement a clock CLOCK_HOST_REALTIME that provides time
information synchronised with the NTP-corrected time
in the Linux kernel.
The definition of the hostrt data is placed
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Augment the shared vdso page with all data required to
implement a clock CLOCK_HOST_REALTIME that provides time
information synchronised with the NTP-corrected time
in the Linux kernel
Including the file only makes sense when support for pervasive
rt is enabled, so add a corresponding check.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/nucleus/vdso.h |4
1 files changed, 4 insertions(+), 0
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
src/testsuite/unit/check-vdso.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/testsuite/unit/check-vdso.c b/src/testsuite/unit/check-vdso.c
index
of pervasive
rt support is compiled in or not.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-generic/hal.h|2 +
include/asm-generic/system.h |4 ++
include/asm-sim/system.h |4 ++
include/nucleus
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-x86/atomic.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86/atomic.h b/include/asm-x86/atomic.h
index bb3ce46..16bc990 100644
into Xenomai. The data exchange
is designed to allow for lockless reading from userland.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/posix/time.h |2 +
ksrc/skins/posix/clock.c | 90
From: Wolfgang Mauerer (none) wolfg...@dirichlet
We can do this since the data are on the shared semaphore heap.
The basis data structure is placed so that it is accessible from
both the Linux kernel and Xenomai kernel/userland. This also
requires to make the structure work with both kernel
... and for reading the contents of the hostrt data.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
---
examples/posix/Makefile |3 +-
examples/posix/show_hrtime.c | 82 ++
2 files changed, 84 insertions(+), 1 deletions(-)
create
Kiszka, Jan wrote:
Wolfgang Mauerer wrote:
... and for reading the contents of the hostrt data.
Just realized: Please also update clocktest. Should already work with
the new clock ID, but requires a cosmetic output patch.
easy enough -- here you go ;-) (I'll integrate this into the series
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
... and for reading the contents of the hostrt data.
Just realized: Please also update clocktest. Should already work with
the new clock ID, but requires a cosmetic output patch.
Yes, I thought about that. Maybe even
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
(This is the Xenomai part of the mechanism, please see the ipipe
mailing list for the patches that provide the required basis
infrastructure)
This patch series extends Xenomai with a new clock, CLOCK_HOST_REALTIME.
It allows for sharing
.
Would such a thing be suitable for mainline?
Regards, Wolfgang
---
commit 9c2a3908ac4aff21022a577552002fc2622d3670
Author: Wolfgang Mauerer wolfgang.maue...@siemens.com
Date: Mon Jun 7 15:34:39 2010 +0200
This patch provides the possibility to check upon timer expiration
how much a timer
Philippe Gerum wrote:
On Tue, 2010-06-08 at 16:21 +0200, Wolfgang Mauerer wrote:
Hi,
the attached patch augments the timer expiration handler with some checks
for excessive timer latencies. Depending on the configuration options, it
freezes the ipipe tracer and creates a list of delayed
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Just like it seems to be the case for Steve (unless I misunderstood his
reply), it is very useful for us being able to time-stamp events in RT
context that need to be correlated with events stamped in
[moved to xenomai-core]
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
- gettimeofday should not have another timebase than
clock_gettime(CLOCK_REALTIME): in other word, the whole clock system
should be based on the ntp clock.
Sorry, I'm not quite sure what you are talking about here
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
On the one hand you make complicated code (which will be costly on low
end hardware) to avoid shutting interrupts around a few assignments, but
on the other hand you leave an architecture specific function pointer
call where we want a fast
From: Wolfgang Mauerer (none) wolfg...@dirichlet
The per_cpu__ prefix for per-cpu-variables in the Linux kernel
is gone since dd17c8f72993f. This patch adapts the x86_64
task switching code to cope with kernels before and after this
commit.
Signed-off-by: Wolfgang Mauerer wolfgang.maue
The per_cpu__ prefix for per-cpu-variables in the Linux kernel
is gone since dd17c8f72993f. This patch adds a corresponding wrapper.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Acked-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-generic/wrappers.h |4
include
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Hi Gilles,
I'm pushing your findings to the list, also as my colleagues showed
strong interest - this thing may explain rare
Jan Kiszka wrote:
If we enter __ipipe_handle_exception over a non-root domain and leave it
due to migration in the event handler over root, we must not restore the
root domain state so far saved on entry. This caused subtle pipeline
state corruptions. Instead, only save and restore them if we
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
If we enter __ipipe_handle_exception over a non-root domain and leave it
due to migration in the event handler over root, we must not restore the
root domain state so far saved on entry. This caused subtle pipeline
state corruptions
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
If we enter __ipipe_handle_exception over a non-root domain and leave it
due to migration in the event handler over root, we must not restore the
root domain state so far saved on entry
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
If we enter __ipipe_handle_exception over a non-root domain and leave it
due to migration in the event handler over root, we must not restore
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Jan Kiszka wrote:
If we enter __ipipe_handle_exception over a non-root domain and leave
it
due to migration
(sorry if you get this twice, the cc addresses were screwed up
by copy and paste last time)
Kiszka, Jan wrote:
If we enter __ipipe_handle_exception over a non-root domain and leave it
due to migration in the event handler over root, we must not restore the
root domain state so far saved on
Jan Kiszka wrote:
Wolfgang Mauerer wrote:
Kiszka, Jan wrote:
If we enter __ipipe_handle_exception over a non-root domain and leave it
due to migration in the event handler over root, we must not restore the
root domain state so far saved on entry. This caused subtle pipeline
state
bit must be added
to the flags.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
include/asm-generic/syscall.h |1 +
include/nucleus/Makefile.am |3 +-
include/nucleus/xnvdso.h | 61
Hi,
the following two mails integrate Gilles' comments into
the xnvdso patch and add a unit test. Notice that this submission
does not consider efficient access of shared data from
kernel space. Since this problem is independent from the
xnvdso mechanism, it will be addressed when I submit the
of them.
In this case, the testcase needs to be extended accordingly
to check that only the expected features are present.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
src/testsuite/unit/Makefile.am | 15 +-
src
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
This testcase checks if the value in xnvdso-features matches the
value of XNVDSO_FEATURES, that is, if the information is correctly
transferred from kernel to userland.
Notice that the approach will fail once configurations are supported
Gilles Chanteperdrix wrote:
wolfgang.maue...@siemens.com wrote:
From: Wolfgang Mauerer wolfgang.maue...@siemens.com
A new structure (struct xnshared) is introduced. It allows us to share
generic data between user and kernel of Linux and Xenomai; a bitmap
of feature flags located
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
+enum xnshared_features {
+/*XNSHARED_FEAT_A = 1,
+ XNSHARED_FEAT_B, */
+ XNSHARED_MAX_FEATURES,
+};
Xenomai style is to use defines bit with the bit shifted directly, so,
XNSHARED_FEAT_A would rather be 0x0001
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
+enum xnshared_features {
+/* XNSHARED_FEAT_A = 1,
+XNSHARED_FEAT_B, */
+XNSHARED_MAX_FEATURES,
+};
Xenomai style is to use defines bit with the bit shifted
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
(...)
Would it
therefore make sense to restrict the data exchange to the global heap
semaphore, and add an architecture-specific
From: Wolfgang Mauerer wolfgang.maue...@siemens.com
A new structure (struct xnshared) is introduced. It allows us to share
generic data between user and kernel of Linux and Xenomai; a bitmap
of feature flags located at the beginning of the structure identifies
which data are shared. The structure
Quoting Philippe Gerum r...@xenomai.org:
On Mon, 2009-12-07 at 14:43 +0100, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Philippe Gerum wrote:
On Thu, 2009-12-03 at 22:42 +0100, Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote
Hi,
On 02.12.2009, at 23:20, Gilles Chanteperdrix gilles.chanteperd...@xenomai.org
wrote:
Wolfgang Mauerer wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I surely don't want to duplicate ntp code, just the results it
spits out
(e.g. into the vdso
Hi,
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
So that means, in essence, that you would accept probabilistic
algorithms in realtime context?
Ah, today's troll!
though it seems that I have to replace Jan this time ;-)
As I think I explained, the use of a seqlock in real-time
Hi,
On 03.12.2009, at 14:14, Gilles Chanteperdrix gilles.chanteperd...@xenomai.org
wrote:
Wolfgang Mauerer wrote:
Hi,
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
So that means, in essence, that you would accept probabilistic
algorithms in realtime context?
Ah, today's troll
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
Hi,
On 03.12.2009, at 14:14, Gilles Chanteperdrix
gilles.chanteperd...@xenomai.org
wrote:
Wolfgang Mauerer wrote:
Hi,
Gilles Chanteperdrix wrote:
Wolfgang Mauerer wrote:
So that means, in essence, that you would accept
Hi,
we'd like to implement a gettimeofday() mechanism that works
in realtime context, both from user- and kernelland. Most importantly,
the correctins made to the wall time by the NTP protcol on Linux
must be transferred into the Xenomai domain. We have a preliminary
implementation (with several
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
I surely don't want to duplicate ntp code, just the results it spits out
(e.g. into the vdso page).
Ok, good point, we can avoid duplicating ntp code, but the vdso page
trick only works on two architectures. So, IMO,
From: Wolfgang Mauerer w...@linux-kernel.net
rtdm_event_wait can return -EWOULDBLOCK when a
negative (i.e., non-blocking) timeout has been specified,
but this is not covered in the documentation.
Signed-off-by: Wolfgang Mauerer wolfgang.maue...@siemens.com
Signed-off-by: Jan Kiszka jan.kis
From: Wolfgang Mauerer w...@linux-kernel.net
The trace mark string for faults uses an address
element to notify about the location of the instruction
that caused the fault. address is a bit dubious in
this context because it can mean either faulting address
or IP address. Replacing address
From: Wolfgang Mauerer wolfgang.maue...@siemens.com
When a Xenomai thread tries to access a deleted
message queue, it should obtain -ESRCH as error code
both from within the kernel and for userland applications.
However, userland sometimes receives wrong error codes
because failure of the handle
59 matches
Mail list logo
