Re: [Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
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 at the beginning of the structure identifies
which data are shared. The structure is allocated in the global semaphore
heap, and xnsysinfo.xnshared_offset identifies the offset of the
structure within the heap.
Currently, no shared features are yet supported - the patch only
introduces the necessary ABI changes. When the need arises
to share data between said entities, the structure must
be accordingly extended, and a new feature bit must be added
to the flags.
Hi,
it is nice that you proposed that patch, I wanted to do it, but did not
yet. Some comments however.
First, I think xnshared/xnshared_offset is a bit of a long name. I was
thinking about xnvdso, but is is only slightly shorter. Any other idea,
anyone?
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/xnshared.h| 33 +
ksrc/nucleus/module.c | 23 +++
ksrc/nucleus/shadow.c |4
4 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 include/nucleus/xnshared.h
diff --git a/include/asm-generic/syscall.h b/include/asm-generic/syscall.h
index 483b99f..7d68580 100644
--- a/include/asm-generic/syscall.h
+++ b/include/asm-generic/syscall.h
@@ -53,6 +53,7 @@
typedef struct xnsysinfo {
unsigned long long cpufreq; /* CPU frequency */
unsigned long tickval; /* Tick duration (ns) */
+ unsigned long xnshared_offset; /* Offset of xnshared in the sem heap */
} xnsysinfo_t;
#define SIGSHADOW SIGWINCH
diff --git a/include/nucleus/xnshared.h b/include/nucleus/xnshared.h
new file mode 100644
index 000..4293cda
--- /dev/null
+++ b/include/nucleus/xnshared.h
@@ -0,0 +1,33 @@
+#ifndef XNSHARED_H
+#define XNSHARED_H
+
+/*
+ * Data shared between Xenomai kernel/userland and the Linux kernel/userland
+ * on the global semaphore heap. The features element indicates which data
are
+ * shared. Notice that xnshared may only grow, but never shrink.
+ */
+struct xnshared {
+ unsigned long long features;
+
+ /* Embed domain specific structures that describe the
+ * shared data here */
+};
+
+/*
+ * For each shared feature, add a flag below. For now, it is still
+ * empty.
+ */
+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, and I am not sure an
enum can be 64 bits.
+
+extern struct xnshared *xnshared;
+
+static inline int xnshared_test_feature(enum xnshared_features feature)
+{
+ return xnshared xnshared-features (1 feature);
+}
xnshared can not be null (you panic when allocation fails), and please
use testbits for this function.
+
+#endif
diff --git a/ksrc/nucleus/module.c b/ksrc/nucleus/module.c
index 5404182..3963fbd 100644
--- a/ksrc/nucleus/module.c
+++ b/ksrc/nucleus/module.c
@@ -34,6 +34,7 @@
#include nucleus/pipe.h
#endif /* CONFIG_XENO_OPT_PIPE */
#include nucleus/select.h
+#include nucleus/xnshared.h
#include asm/xenomai/bits/init.h
MODULE_DESCRIPTION(Xenomai nucleus);
@@ -51,6 +52,9 @@ u_long xnmod_sysheap_size;
int xeno_nucleus_status = -EINVAL;
+struct xnshared *xnshared;
+EXPORT_SYMBOL_GPL(xnshared);
+
struct xnsys_ppd __xnsys_global_ppd;
EXPORT_SYMBOL_GPL(__xnsys_global_ppd);
@@ -82,6 +86,23 @@ void xnmod_alloc_glinks(xnqueue_t *freehq)
}
EXPORT_SYMBOL_GPL(xnmod_alloc_glinks);
+/*
+ * We re-use the global semaphore heap to provide a multi-purpose shared
+ * memory area between Xenomai and Linux - for both kernel and userland
+ */
+void __init xnheap_init_shared(void)
+{
+ xnshared = (struct xnshared *)xnheap_alloc(__xnsys_global_ppd.sem_heap,
+ sizeof(struct xnshared));
+
+ if (!xnshared)
+ xnpod_fatal(Xenomai: cannot allocate memory for xnshared!\n);
+
+ /* Currently, we don't support any sharing, but later versions will
+ * add flags here */
+ xnshared-features = 0ULL;
+}
+
int __init __xeno_sys_init(void)
{
int ret;
@@ -106,6 +127,8 @@ int __init __xeno_sys_init(void)
goto cleanup_arch;
xnheap_set_label(__xnsys_global_ppd.sem_heap, global sem heap);
+
+ xnheap_init_shared();
#endif
Ok. There is a real question here. Whether we want to put this code in
module.c or shadow.c. I have no definite answer. Arguments for each file:
module.c: the shared area will be used for NTP by the
Re: [Xenomai-core] Remove outdated x86 adeos patches
On Tue, 2009-12-22 at 00:06 +0100, Gilles Chanteperdrix wrote: Philippe Gerum wrote: On Mon, 2009-12-21 at 09:58 +0100, Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Philippe, as adeos-ipipe-2.4.35.5-i386-1.3-05.patch and adeos-ipipe-2.6.29.5-x86-2.4-02.patch are no longer up to date /wrt to latest i-pipe fixes, I would suggest to remove them for 2.5-final. Avoids that people trap into known issues. What latest fixes? Are they expected to oops or something? 2.6.29 on x86-64: definitely (irq stack corruption). 32 bits and 2.4.35 are lacking the halt fix (I bet other arch beyond x86 that use a hlt-like idle do so as well). It's not that they aren't fixable, it's just the question if we should bother anymore. Ack. I don't even know whether anybody ever tried to run Xenomai over 2.4/x86 anyway, and I don't think this would ever make sense to do so today, so 2.4.35 will be removed. 2.6.29.4 will go away as well, since 2.6.30.8 and 2.6.31.1 have been fixed, and hopefully, 2.6.33/86 will be supported in a foreseeable future. In any case, the README in the patches/ directory clearly states that adventurous people may try other options available from http://download.gna.org/adeos/patches/ Ok. However, if we want to check that Xenomai 2.5 still compiles with linux 2.4 base patches, can we keep at least one 2.4 patch in the repository? 2.4.25-ppc is here to stay. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Hi, Since I started talking about it, I have run build tests fixing a few things here and there. The current status is this (still at the same place: http://sisyphus.hd.free.fr/~gilles/bx): * analogy: I have tried to disable some parts of analogy when compiling on machines without CONFIG_PCI, as compiling parts using PCI on a machine without PCI support, give various levels of warning and even errors depending on the architecture. Doing this, I stumbled across this compilation error: http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1 this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE. So, Alex, could you: - fix that error, if this combination is supposed to make sense - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI is not set (I tried and do this myself, but better one who knows than 100 who have to search...). As I said, doing this result in various levels of success depending on the architecture. * blackfin: I finally compiled blackfin! had to build a toolchain for that as the binary-only toolchain from analog.com uses glibc 2.8 and mine is 2.7. However, blackfin does not compile very well, as can be seen by the log: http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1 It may happen that my toolchain is buggy or outdated though. * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? * nios2: I am lacking some important file needed to even start to compile. Thanks in advance for your efforts. Regards. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Pull request: build fixes.
The following changes since commit 0cb257bf7393b5a53eb35b021b95730bd40dd561: Philippe Gerum (1): Merge commit 'gilles' are available in the git repository at: git://git.xenomai.org/xenomai-gch.git for-head Gilles Chanteperdrix (3): arith: avoid ARM Linux do_div compile-time optimizations. analogy: do not compile pcimio on kernels without PCI support rtdm: include the new pci_ids driver through rtdm include/asm-generic/arith.h | 14 +++--- include/rtdm/rtdm_driver.h|3 +++ ksrc/drivers/analogy/national_instruments/Kconfig |2 +- ksrc/drivers/can/sja1000/rtcan_ems_pci.c |1 - ksrc/drivers/can/sja1000/rtcan_esd_pci.c |1 - ksrc/drivers/can/sja1000/rtcan_ixxat_pci.c|1 - ksrc/drivers/can/sja1000/rtcan_peak_pci.c |1 - 7 files changed, 15 insertions(+), 8 deletions(-) -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
On Tue, 2009-12-22 at 11:06 +0100, Gilles Chanteperdrix wrote: Hi, Since I started talking about it, I have run build tests fixing a few things here and there. The current status is this (still at the same place: http://sisyphus.hd.free.fr/~gilles/bx): * analogy: I have tried to disable some parts of analogy when compiling on machines without CONFIG_PCI, as compiling parts using PCI on a machine without PCI support, give various levels of warning and even errors depending on the architecture. Doing this, I stumbled across this compilation error: http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1 this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE. So, Alex, could you: - fix that error, if this combination is supposed to make sense - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI is not set (I tried and do this myself, but better one who knows than 100 who have to search...). As I said, doing this result in various levels of success depending on the architecture. * blackfin: I finally compiled blackfin! Good. So now you can try fixing the climate. had to build a toolchain for that as the binary-only toolchain from analog.com uses glibc 2.8 and mine is 2.7. However, blackfin does not compile very well, as can be seen by the log: http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1 It may happen that my toolchain is buggy or outdated though. 4.1.2 might still have the mcount prologue issue, so no tracer, but aside of this, it seems ok here. I've just pushed fixes for the NMI braindamage for blackfin. * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? * nios2: I am lacking some important file needed to even start to compile. I'm on this. Thanks in advance for your efforts. Regards. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai-git Digest, Vol 9, Issue 40
Gilles Chanteperdrix wrote: Jan Kiszka wrote: xenomai-git-requ...@gna.org wrote: Date: Mon, 21 Dec 2009 16:04:33 +0100 From: GIT version control g...@xenomai.org Subject: [Xenomai-git] Gilles Chanteperdrix : rtcan: use the new pci_ids header for pci rtcan drivers To: xenomai-...@gna.org Message-ID: e1nmjoh-0003st...@xenomai.org Content-Type: text/plain; charset=UTF-8 Module: xenomai-head Branch: master Commit: 5662ced95f1f51dbf4285d5ff5a6da84cc74af83 URL: http://git.xenomai.org/?p=xenomai-head.git;a=commit;h=5662ced95f1f51dbf4285d5ff5a6da84cc74af83 Author: Gilles Chanteperdrix gilles.chanteperd...@xenomai.org Date: Sun Dec 20 02:43:36 2009 +0100 rtcan: use the new pci_ids header for pci rtcan drivers --- ksrc/drivers/can/sja1000/rtcan_ems_pci.c |1 + ksrc/drivers/can/sja1000/rtcan_esd_pci.c |1 + ksrc/drivers/can/sja1000/rtcan_ixxat_pci.c |1 + ksrc/drivers/can/sja1000/rtcan_peak_pci.c |1 + 4 files changed, 4 insertions(+), 0 deletions(-) diff --git a/ksrc/drivers/can/sja1000/rtcan_ems_pci.c b/ksrc/drivers/can/sja1000/rtcan_ems_pci.c index f69b5b8..a0921b4 100644 --- a/ksrc/drivers/can/sja1000/rtcan_ems_pci.c +++ b/ksrc/drivers/can/sja1000/rtcan_ems_pci.c @@ -23,6 +23,7 @@ #include linux/delay.h #include linux/pci.h #include asm/io.h +#include asm-generic/xenomai/pci_ids.h Is there any prerequisite for including this header? If not, can't we drag it in via Xenomai's rtdm_driver.h? That avoids diverging too much from the only Linux or RTDM rule in our drivers. I understand, RTcan would not compile with RTAI. This header is also Right (though I was more concerned about native RTDM :) ). used by the smi module, which is not an RTDM module, that said we can include it through RTDM for RTDM drivers, and smi module would include it directly. Great, TIA. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Gilles Chanteperdrix wrote: * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h), it must not be called differently. Blackfin is obviously doing namespace pollution which should be fixed upstream and meanwhile worked around in Xenomai (e.g. via #undef CAN_ERR_MASK). Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Jan Kiszka wrote: Gilles Chanteperdrix wrote: * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h), it must not be called differently. Blackfin is obviously doing namespace pollution which should be fixed upstream and meanwhile worked around in Xenomai (e.g. via #undef CAN_ERR_MASK). Ok. But according to the build logs, it is redefined in rtdm/rtcan.h. The error seems to have been fixed upstream, since we get this warning with 2.6.30 and not with 2.6.31. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
Gilles Chanteperdrix wrote:
wolfgang.maue...@siemens.com wrote:
+/*
+ * We re-use the global semaphore heap to provide a multi-purpose shared
+ * memory area between Xenomai and Linux - for both kernel and userland
+ */
+void __init xnheap_init_shared(void)
+{
+xnshared = (struct xnshared *)xnheap_alloc(__xnsys_global_ppd.sem_heap,
+ sizeof(struct xnshared));
Also:
Xenomai style: s/sizeof(struct xnshared)/sizeof(*xnshared)/
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h), it must not be called differently. Blackfin is obviously doing namespace pollution which should be fixed upstream and meanwhile worked around in Xenomai (e.g. via #undef CAN_ERR_MASK). Ok. But according to the build logs, it is redefined in rtdm/rtcan.h. The error seems to have been fixed upstream, since we get this warning with 2.6.30 and not with 2.6.31. The RT-SocketCAN API is compatible with the SocketCAN API and therefore we should not use different names. And there are much more common defines and names. It is simply stupid to include that header file in a central place. I tend to fix this be adding #ifndef to rtnet.h. I will have a closer look later. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h), it must not be called differently. Blackfin is obviously doing namespace pollution which should be fixed upstream and meanwhile worked around in Xenomai (e.g. via #undef CAN_ERR_MASK). Ok. But according to the build logs, it is redefined in rtdm/rtcan.h. The error seems to have been fixed upstream, since we get this warning with 2.6.30 and not with 2.6.31. Right, the error comes from: http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20 and is in conflict with include/linux/can/can.h anyhow. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
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 at the beginning of the structure identifies
which data are shared. The structure is allocated in the global semaphore
heap, and xnsysinfo.xnshared_offset identifies the offset of the
structure within the heap.
Currently, no shared features are yet supported - the patch only
introduces the necessary ABI changes. When the need arises
to share data between said entities, the structure must
be accordingly extended, and a new feature bit must be added
to the flags.
Hi,
it is nice that you proposed that patch, I wanted to do it, but did not
yet. Some comments however.
you're welcome ;-) I have some more patches pending that I have not
sent yet because they need some polishing, so it might make
sense to coordinate things first before you start to work on any of
the issues.
A patch including the changes you requested is attached.
First, I think xnshared/xnshared_offset is a bit of a long name. I was
thinking about xnvdso, but is is only slightly shorter. Any other idea,
anyone?
we can use xnvdso and xnvdso_off to save a few chars, I don't have any
real preferences wrt. naming.
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/xnshared.h| 33 +
ksrc/nucleus/module.c | 23 +++
ksrc/nucleus/shadow.c |4
4 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 include/nucleus/xnshared.h
diff --git a/include/asm-generic/syscall.h b/include/asm-generic/syscall.h
index 483b99f..7d68580 100644
--- a/include/asm-generic/syscall.h
+++ b/include/asm-generic/syscall.h
@@ -53,6 +53,7 @@
typedef struct xnsysinfo {
unsigned long long cpufreq; /* CPU frequency */
unsigned long tickval; /* Tick duration (ns) */
+unsigned long xnshared_offset; /* Offset of xnshared in the sem heap */
} xnsysinfo_t;
#define SIGSHADOW SIGWINCH
diff --git a/include/nucleus/xnshared.h b/include/nucleus/xnshared.h
new file mode 100644
index 000..4293cda
--- /dev/null
+++ b/include/nucleus/xnshared.h
@@ -0,0 +1,33 @@
+#ifndef XNSHARED_H
+#define XNSHARED_H
+
+/*
+ * Data shared between Xenomai kernel/userland and the Linux kernel/userland
+ * on the global semaphore heap. The features element indicates which data
are
+ * shared. Notice that xnshared may only grow, but never shrink.
+ */
+struct xnshared {
+unsigned long long features;
+
+/* Embed domain specific structures that describe the
+ * shared data here */
+};
+
+/*
+ * For each shared feature, add a flag below. For now, it is still
+ * empty.
+ */
+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, and I am not sure an
enum can be 64 bits.
oh yeah, enums are always ints, as a superficial look into the
ANSI standard tells me. Wasn't thinking about that. Using
your direct definition makes sense (although it's a bit
unlikely that there will ever be more than 2^32 shared
features...)
+
+extern struct xnshared *xnshared;
+
+static inline int xnshared_test_feature(enum xnshared_features feature)
+{
+return xnshared xnshared-features (1 feature);
+}
xnshared can not be null (you panic when allocation fails), and please
use testbits for this function.
okay
+
+#endif
diff --git a/ksrc/nucleus/module.c b/ksrc/nucleus/module.c
index 5404182..3963fbd 100644
--- a/ksrc/nucleus/module.c
+++ b/ksrc/nucleus/module.c
@@ -34,6 +34,7 @@
#include nucleus/pipe.h
#endif /* CONFIG_XENO_OPT_PIPE */
#include nucleus/select.h
+#include nucleus/xnshared.h
#include asm/xenomai/bits/init.h
MODULE_DESCRIPTION(Xenomai nucleus);
@@ -51,6 +52,9 @@ u_long xnmod_sysheap_size;
int xeno_nucleus_status = -EINVAL;
+struct xnshared *xnshared;
+EXPORT_SYMBOL_GPL(xnshared);
+
struct xnsys_ppd __xnsys_global_ppd;
EXPORT_SYMBOL_GPL(__xnsys_global_ppd);
@@ -82,6 +86,23 @@ void xnmod_alloc_glinks(xnqueue_t *freehq)
}
EXPORT_SYMBOL_GPL(xnmod_alloc_glinks);
+/*
+ * We re-use the global semaphore heap to provide a multi-purpose shared
+ * memory area between Xenomai and Linux - for both kernel and userland
+ */
+void __init xnheap_init_shared(void)
+{
+xnshared = (struct xnshared *)xnheap_alloc(__xnsys_global_ppd.sem_heap,
+ sizeof(struct xnshared));
+
+if (!xnshared)
+xnpod_fatal(Xenomai:
Re: [Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
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, and I am not sure an
enum can be 64 bits.
oh yeah, enums are always ints, as a superficial look into the
ANSI standard tells me. Wasn't thinking about that. Using
your direct definition makes sense (although it's a bit
unlikely that there will ever be more than 2^32 shared
features...)
Err, since features are bits, the limit is 32 features, not 2^32, and if
we make the features member an unsigned long long in the first place, it
is because we expect to be able to use the 64 bits, no?
Ok. There is a real question here. Whether we want to put this code in
module.c or shadow.c. I have no definite answer. Arguments for each file:
module.c: the shared area will be used for NTP by the clock/timer
subsystem, so will be used in kernel-space, even without
CONFIG_XENO_OPT_PERVASIVE.
shadow.c: global shared heap is uncached on ARM, so, I am not sure we
really want the timer/clock system to use the same area as user-space.
So, we are probably better off using different copies of the same data
in kernel-space and user-space (with a price of a copy every time the
data change and CONFIG_XENO_OPT_PERVASIVE is enabled). This would allow
us to move that code in shadow.c
Is there any compelling advantage for shadow.c? Using a copy operation
every time the data change seems a bit contrary to the reason for
the new mechanism in the first place, namely to have a light-weight
means of sharing data.
The way I see it, the NTP data will be used by the nucleus clock and
timer subsystem, so several times for each timer tick, so having them on
an uncached memory will have a performance hit.
The copy, on the other hand, would take place over a non real-time
context, only once every update of NTP data, i.e. once every 10ms.
So, let us move it to shadow.c.
#ifdef __KERNEL__
diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index 0c94a60..0373a8d 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -50,6 +50,7 @@
#include nucleus/trace.h
#include nucleus/stat.h
#include nucleus/sys_ppd.h
+#include nucleus/xnshared.h
#include asm/xenomai/features.h
#include asm/xenomai/syscall.h
#include asm/xenomai/bits/shadow.h
@@ -1746,6 +1747,9 @@ static int xnshadow_sys_info(struct pt_regs *regs)
info.cpufreq = xnarch_get_cpu_freq();
+ info.xnshared_offset =
+ xnheap_mapped_offset(xnsys_ppd_get(1)-sem_heap, xnshared);
+
return __xn_safe_copy_to_user((void __user *)infarg, info,
sizeof(info));
}
And the user-space part? It would be nice to at least define the
structure in user-space and read the features member, to check that
the inclusion of the nucleus/xnshared header works and that we read 0
and there is no gag on all architectures
We can not expect to read 0, since we want this user-space to continue
working with later versions of the ABI. Actually, we can not expect
features to be of an specific form (I was thinking (1 max_bit) - 1,
but it would mean that we can not remove feature bits).
I haven't included the userland part on purpose because I wanted
to make sure that the ABI change is merged for 2.5 - all the rest
can be added later without problems. It will follow once I've
polished the code (if having the userland part should be
a prerequisite for merging the ABI change, I can try to speed
things up a bit; otherwise, I'd submit the userland read side
together with the NTP base mechanics).
It would be embarassing (though unlikely) to think having changed the
ABI, and finally find out, when we start to use it, that the ABI change
does not work. So, please add the user-space code. So, that our run-time
tests on various architectures can be used to check that the
modification actually works.
The really really nice thing to do, would be a unit test which checks
for a specific value of the ABI features. So, we can run
check_xeno_abi_features 0, to check that the thing actually works with
release 2.5.0.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Wolfgang Grandegger wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h), it must not be called differently. Blackfin is obviously doing namespace pollution which should be fixed upstream and meanwhile worked around in Xenomai (e.g. via #undef CAN_ERR_MASK). Ok. But according to the build logs, it is redefined in rtdm/rtcan.h. The error seems to have been fixed upstream, since we get this warning with 2.6.30 and not with 2.6.31. Right, the error comes from: http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20 and is in conflict with include/linux/can/can.h anyhow. Ok, ok. My question was about rtdm/rtcan.h redefining what is already defined in linux/can.h. Would not it make sense to include linux/can.h instead? Of course, this is not something that needs fixing right now, but would be better on the long run. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h), it must not be called differently. Blackfin is obviously doing namespace pollution which should be fixed upstream and meanwhile worked around in Xenomai (e.g. via #undef CAN_ERR_MASK). Ok. But according to the build logs, it is redefined in rtdm/rtcan.h. The error seems to have been fixed upstream, since we get this warning with 2.6.30 and not with 2.6.31. Right, the error comes from: http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20 and is in conflict with include/linux/can/can.h anyhow. Ok, ok. My question was about rtdm/rtcan.h redefining what is already defined in linux/can.h. Would not it make sense to include linux/can.h instead? Of course, this is not something that needs fixing right now, but would be better on the long run. Right. We just need to take care for pre-CAN kernels. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Jan Kiszka wrote: Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h), it must not be called differently. Blackfin is obviously doing namespace pollution which should be fixed upstream and meanwhile worked around in Xenomai (e.g. via #undef CAN_ERR_MASK). Ok. But according to the build logs, it is redefined in rtdm/rtcan.h. The error seems to have been fixed upstream, since we get this warning with 2.6.30 and not with 2.6.31. Right, the error comes from: http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20 and is in conflict with include/linux/can/can.h anyhow. Ok, ok. My question was about rtdm/rtcan.h redefining what is already defined in linux/can.h. Would not it make sense to include linux/can.h instead? Of course, this is not something that needs fixing right now, but would be better on the long run. Right. We just need to take care for pre-CAN kernels. In wrappers.h, as we do for every other variation of the kernel interface. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
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, and I am not sure an
enum can be 64 bits.
oh yeah, enums are always ints, as a superficial look into the
ANSI standard tells me. Wasn't thinking about that. Using
your direct definition makes sense (although it's a bit
unlikely that there will ever be more than 2^32 shared
features...)
Err, since features are bits, the limit is 32 features, not 2^32, and if
we make the features member an unsigned long long in the first place, it
is because we expect to be able to use the 64 bits, no?
Argl. Yes. /me realises that christmas holidays are severely required...
Ok. There is a real question here. Whether we want to put this code in
module.c or shadow.c. I have no definite answer. Arguments for each file:
module.c: the shared area will be used for NTP by the clock/timer
subsystem, so will be used in kernel-space, even without
CONFIG_XENO_OPT_PERVASIVE.
shadow.c: global shared heap is uncached on ARM, so, I am not sure we
really want the timer/clock system to use the same area as user-space.
So, we are probably better off using different copies of the same data
in kernel-space and user-space (with a price of a copy every time the
data change and CONFIG_XENO_OPT_PERVASIVE is enabled). This would allow
us to move that code in shadow.c
Is there any compelling advantage for shadow.c? Using a copy operation
every time the data change seems a bit contrary to the reason for
the new mechanism in the first place, namely to have a light-weight
means of sharing data.
The way I see it, the NTP data will be used by the nucleus clock and
timer subsystem, so several times for each timer tick, so having them on
an uncached memory will have a performance hit.
The copy, on the other hand, would take place over a non real-time
context, only once every update of NTP data, i.e. once every 10ms.
So, let us move it to shadow.c.
I see your point, but it has the disadvantage that the time spent
in the Linux kernel for the copy operations in the vsyscall is
increased -- which might affect the Linux domain, since this is
an optimised hot path. Naturally, in the absence of any quantitative
measurements, this is all just speculation, but if access to the global
semaphore heap is unchached only on ARM, we provide an unnecessary
optimisation for n-1 out of n architectures supported by Xenomai.
Having the time-keeping code in the Xenomai kernel benefit from NTP
corrections provided by the Linux side is a bit separate from the
ABI change, which would be the same irregardless of whether we
use a second copy for kernel-side NTP operations or not. Would it
therefore make sense to restrict the data exchange to the global heap
semaphore, and add an architecture-specific hook for ARM
later on to generate an extra kernel space copy of the NTP data? The
Linux vsyscall time keeping information is architecture-specific, so
arch specific hooks make sense in this area anyway. We could therefore
restrict the second copy to ARM without much effort. Or am I missing
something in your considerations?
#ifdef __KERNEL__
diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
index 0c94a60..0373a8d 100644
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -50,6 +50,7 @@
#include nucleus/trace.h
#include nucleus/stat.h
#include nucleus/sys_ppd.h
+#include nucleus/xnshared.h
#include asm/xenomai/features.h
#include asm/xenomai/syscall.h
#include asm/xenomai/bits/shadow.h
@@ -1746,6 +1747,9 @@ static int xnshadow_sys_info(struct pt_regs *regs)
info.cpufreq = xnarch_get_cpu_freq();
+ info.xnshared_offset =
+xnheap_mapped_offset(xnsys_ppd_get(1)-sem_heap, xnshared);
+
return __xn_safe_copy_to_user((void __user *)infarg, info,
sizeof(info));
}
And the user-space part? It would be nice to at least define the
structure in user-space and read the features member, to check that
the inclusion of the nucleus/xnshared header works and that we read 0
and there is no gag on all architectures
We can not expect to read 0, since we want this user-space to continue
working with later versions of the ABI. Actually, we can not expect
features to be of an specific form (I was thinking (1 max_bit) - 1,
but it would mean that we can not remove feature bits).
I haven't included the userland part on purpose because I wanted
to make sure that the ABI change is merged for 2.5 - all the rest
can be added later without problems. It will follow once I've
polished the code (if having the userland part should be
a prerequisite for merging the ABI change, I can try to speed
things up a bit; otherwise, I'd submit the userland read side
together with the NTP base mechanics).
It
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Hi Gilles, Gilles Chanteperdrix a écrit : Hi, Since I started talking about it, I have run build tests fixing a few things here and there. The current status is this (still at the same place: http://sisyphus.hd.free.fr/~gilles/bx): * analogy: I have tried to disable some parts of analogy when compiling on machines without CONFIG_PCI, as compiling parts using PCI on a machine without PCI support, give various levels of warning and even errors depending on the architecture. Doing this, I stumbled across this compilation error: http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1 this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE. So, Alex, could you: - fix that error, if this combination is supposed to make sense - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI is not set (I tried and do this myself, but better one who knows than 100 who have to search...). As I said, doing this result in various levels of success depending on the architecture. * blackfin: I finally compiled blackfin! had to build a toolchain for that as the binary-only toolchain from analog.com uses glibc 2.8 and mine is 2.7. However, blackfin does not compile very well, as can be seen by the log: http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1 It may happen that my toolchain is buggy or outdated though. * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? * nios2: I am lacking some important file needed to even start to compile. You may use this tutorial on how to use Xenomai on NIOS 2 softcore processor: http://uuu.enseirb.fr/~kadionik/nios-xenomai/Xenomai%20on%20NIOS%20II%20Softcore%20Processor.%20A%20step%20by%20step%20Guide.pdf Regards, Pat. Thanks in advance for your efforts. Regards. -- Patrice Kadionik. F6KQH / F4CUQ --- +--+ +Tout doit etre aussi simple que possible, pas seulement plus simple + +--+ + Patrice Kadionik http://www.enseirb.fr/~kadionik + + IMS Laboratory http://www.ims-bordeaux.fr/ + + ENSEIRB http://www.enseirb.fr + + PO BOX 99fax : +33 5.56.37.20.23 + + 33402 TALENCE Cedex voice : +33 5.56.84.23.47 + + FRANCE mailto:patrice.kadio...@ims-bordeaux.fr + +--+ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
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 directly, so,
XNSHARED_FEAT_A would rather be 0x0001, and I am not sure an
enum can be 64 bits.
oh yeah, enums are always ints, as a superficial look into the
ANSI standard tells me. Wasn't thinking about that. Using
your direct definition makes sense (although it's a bit
unlikely that there will ever be more than 2^32 shared
features...)
Err, since features are bits, the limit is 32 features, not 2^32, and if
we make the features member an unsigned long long in the first place, it
is because we expect to be able to use the 64 bits, no?
Argl. Yes. /me realises that christmas holidays are severely required...
Ok. There is a real question here. Whether we want to put this code in
module.c or shadow.c. I have no definite answer. Arguments for each file:
module.c: the shared area will be used for NTP by the clock/timer
subsystem, so will be used in kernel-space, even without
CONFIG_XENO_OPT_PERVASIVE.
shadow.c: global shared heap is uncached on ARM, so, I am not sure we
really want the timer/clock system to use the same area as user-space.
So, we are probably better off using different copies of the same data
in kernel-space and user-space (with a price of a copy every time the
data change and CONFIG_XENO_OPT_PERVASIVE is enabled). This would allow
us to move that code in shadow.c
Is there any compelling advantage for shadow.c? Using a copy operation
every time the data change seems a bit contrary to the reason for
the new mechanism in the first place, namely to have a light-weight
means of sharing data.
The way I see it, the NTP data will be used by the nucleus clock and
timer subsystem, so several times for each timer tick, so having them on
an uncached memory will have a performance hit.
The copy, on the other hand, would take place over a non real-time
context, only once every update of NTP data, i.e. once every 10ms.
So, let us move it to shadow.c.
I see your point, but it has the disadvantage that the time spent
in the Linux kernel for the copy operations in the vsyscall is
increased -- which might affect the Linux domain, since this is
an optimised hot path. Naturally, in the absence of any quantitative
measurements, this is all just speculation, but if access to the global
semaphore heap is unchached only on ARM, we provide an unnecessary
optimisation for n-1 out of n architectures supported by Xenomai.
Having the time-keeping code in the Xenomai kernel benefit from NTP
corrections provided by the Linux side is a bit separate from the
ABI change, which would be the same irregardless of whether we
use a second copy for kernel-side NTP operations or not.
Exactly, the issue are distinct, the ABI change is a pure user-space
issue, so, should only be compiled if CONFIG_XENO_OPT_PERVASIVE is defined.
Would it
therefore make sense to restrict the data exchange to the global heap
semaphore, and add an architecture-specific hook for ARM
later on to generate an extra kernel space copy of the NTP data? The
Linux vsyscall time keeping information is architecture-specific, so
No. We will make it generic. Nothing arch specific is needed. We will
not copy the vsyscall time keeping information, we will copy the data
passed to update_vsyscall, which are the same on all architectures.
arch specific hooks make sense in this area anyway. We could therefore
restrict the second copy to ARM without much effort. Or am I missing
something in your considerations?
This xnvdso feature is needed for user-space only. Let us move it to
shadow.c.
The really really nice thing to do, would be a unit test which checks
for a specific value of the ABI features. So, we can run
check_xeno_abi_features 0, to check that the thing actually works with
release 2.5.0.
okay, so I'll make sure to have the userland bits ready in time
before the 2.5.0 release.
You can implement the user-space part only in a unit test, if it is
easier. All that I ask, is to be able to test that it works.
Cheers, Wolfgang
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? CAN_ERR_MASK is part of the Socket-CAN interface (include/linux/can.h), it must not be called differently. Blackfin is obviously doing namespace pollution which should be fixed upstream and meanwhile worked around in Xenomai (e.g. via #undef CAN_ERR_MASK). Ok. But according to the build logs, it is redefined in rtdm/rtcan.h. The error seems to have been fixed upstream, since we get this warning with 2.6.30 and not with 2.6.31. Right, the error comes from: http://lxr.linux.no/#linux+v2.6.32/arch/blackfin/mach-bf537/include/mach/bf537.h#L20 and is in conflict with include/linux/can/can.h anyhow. Ok, ok. My question was about rtdm/rtcan.h redefining what is already defined in linux/can.h. Would not it make sense to include linux/can.h instead? Of course, this is not something that needs fixing right now, but would be better on the long run. Right. We just need to take care for pre-CAN kernels. In wrappers.h, as we do for every other variation of the kernel interface. Yes, I'm going to work on RT-Socket-CAN soon anyhow. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
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 directly, so,
XNSHARED_FEAT_A would rather be 0x0001, and I am not sure an
enum can be 64 bits.
oh yeah, enums are always ints, as a superficial look into the
ANSI standard tells me. Wasn't thinking about that. Using
your direct definition makes sense (although it's a bit
unlikely that there will ever be more than 2^32 shared
features...)
Err, since features are bits, the limit is 32 features, not 2^32, and if
we make the features member an unsigned long long in the first place, it
is because we expect to be able to use the 64 bits, no?
Argl. Yes. /me realises that christmas holidays are severely required...
Ok. There is a real question here. Whether we want to put this code in
module.c or shadow.c. I have no definite answer. Arguments for each file:
module.c: the shared area will be used for NTP by the clock/timer
subsystem, so will be used in kernel-space, even without
CONFIG_XENO_OPT_PERVASIVE.
shadow.c: global shared heap is uncached on ARM, so, I am not sure we
really want the timer/clock system to use the same area as user-space.
So, we are probably better off using different copies of the same data
in kernel-space and user-space (with a price of a copy every time the
data change and CONFIG_XENO_OPT_PERVASIVE is enabled). This would allow
us to move that code in shadow.c
Is there any compelling advantage for shadow.c? Using a copy operation
every time the data change seems a bit contrary to the reason for
the new mechanism in the first place, namely to have a light-weight
means of sharing data.
The way I see it, the NTP data will be used by the nucleus clock and
timer subsystem, so several times for each timer tick, so having them on
an uncached memory will have a performance hit.
The copy, on the other hand, would take place over a non real-time
context, only once every update of NTP data, i.e. once every 10ms.
So, let us move it to shadow.c.
I see your point, but it has the disadvantage that the time spent
in the Linux kernel for the copy operations in the vsyscall is
increased -- which might affect the Linux domain, since this is
an optimised hot path. Naturally, in the absence of any quantitative
measurements, this is all just speculation, but if access to the global
semaphore heap is unchached only on ARM, we provide an unnecessary
optimisation for n-1 out of n architectures supported by Xenomai.
Having the time-keeping code in the Xenomai kernel benefit from NTP
corrections provided by the Linux side is a bit separate from the
ABI change, which would be the same irregardless of whether we
use a second copy for kernel-side NTP operations or not.
Exactly, the issue are distinct, the ABI change is a pure user-space
issue, so, should only be compiled if CONFIG_XENO_OPT_PERVASIVE is defined.
okay, that makes sense.
Would it
therefore make sense to restrict the data exchange to the global heap
semaphore, and add an architecture-specific hook for ARM
later on to generate an extra kernel space copy of the NTP data? The
Linux vsyscall time keeping information is architecture-specific, so
No. We will make it generic. Nothing arch specific is needed. We will
not copy the vsyscall time keeping information, we will copy the data
passed to update_vsyscall, which are the same on all architectures.
Having the possibility to use gettimeofday() without switching to
kernel mode is all about speed, and I don't see why re-using the
optimised data structures offered by the Linux kernel, together with the
already existing optimised read routines for this purpose
should not be an option for the Xenomai userland. But again, the
difference between the alternatives is hard to judge without
quantitative measurements. I'll maybe come back to this.
arch specific hooks make sense in this area anyway. We could therefore
restrict the second copy to ARM without much effort. Or am I missing
something in your considerations?
This xnvdso feature is needed for user-space only. Let us move it to
shadow.c.
okay.
Regards, Wolfgang
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Gilles Chanteperdrix a écrit : Hi, Since I started talking about it, I have run build tests fixing a few things here and there. The current status is this (still at the same place: http://sisyphus.hd.free.fr/~gilles/bx): Hi, I've watched your log file for nios2 (http://sisyphus.hd.free.fr/~gilles/bx/nios2/2.6.30-nios2-linux-uclibc-gcc-3.4.6/log.html#1). You have this error because you don't have generated before the HW design for the NIOS softcore processor: after synthesis with the Quartus Altera tools, you finally have a file for programming the FPGA circuit and a .ptf file that gives ASCII informations on your SoPC design (in a xml style...). The error: ./arch/nios2/Makefile:131: *** Run make hwselect SYSPTF=system.ptf first. Stop. is due to lack of this .ptf file. This command generates a .h (nios2.h) file that makes relation between hardware and the Linux kernel (peripheral base address, irq number, peripheral name...) Please find here: http://uuu.enseirb.fr/~kadionik/nios-xenomai/std_1s10.ptf a valid .ptf file for Xenomai port. Juste run : $ make hwselect SYSPTF=path_to_std_1s10.ptf for completing the kernel compilation... Pat. * analogy: I have tried to disable some parts of analogy when compiling on machines without CONFIG_PCI, as compiling parts using PCI on a machine without PCI support, give various levels of warning and even errors depending on the architecture. Doing this, I stumbled across this compilation error: http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1 this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE. So, Alex, could you: - fix that error, if this combination is supposed to make sense - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI is not set (I tried and do this myself, but better one who knows than 100 who have to search...). As I said, doing this result in various levels of success depending on the architecture. * blackfin: I finally compiled blackfin! had to build a toolchain for that as the binary-only toolchain from analog.com uses glibc 2.8 and mine is 2.7. However, blackfin does not compile very well, as can be seen by the log: http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1 It may happen that my toolchain is buggy or outdated though. * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? * nios2: I am lacking some important file needed to even start to compile. Thanks in advance for your efforts. Regards. -- Patrice Kadionik. F6KQH / F4CUQ --- +--+ +Tout doit etre aussi simple que possible, pas seulement plus simple + +--+ + Patrice Kadionik http://www.enseirb.fr/~kadionik + + IMS Laboratory http://www.ims-bordeaux.fr/ + + ENSEIRB http://www.enseirb.fr + + PO BOX 99fax : +33 5.56.37.20.23 + + 33402 TALENCE Cedex voice : +33 5.56.84.23.47 + + FRANCE mailto:patrice.kadio...@ims-bordeaux.fr + +--+ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
Wolfgang Mauerer wrote:
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 directly, so,
XNSHARED_FEAT_A would rather be 0x0001, and I am not sure an
enum can be 64 bits.
oh yeah, enums are always ints, as a superficial look into the
ANSI standard tells me. Wasn't thinking about that. Using
your direct definition makes sense (although it's a bit
unlikely that there will ever be more than 2^32 shared
features...)
Err, since features are bits, the limit is 32 features, not 2^32, and if
we make the features member an unsigned long long in the first place, it
is because we expect to be able to use the 64 bits, no?
Argl. Yes. /me realises that christmas holidays are severely required...
Ok. There is a real question here. Whether we want to put this code in
module.c or shadow.c. I have no definite answer. Arguments for each file:
module.c: the shared area will be used for NTP by the clock/timer
subsystem, so will be used in kernel-space, even without
CONFIG_XENO_OPT_PERVASIVE.
shadow.c: global shared heap is uncached on ARM, so, I am not sure we
really want the timer/clock system to use the same area as user-space.
So, we are probably better off using different copies of the same data
in kernel-space and user-space (with a price of a copy every time the
data change and CONFIG_XENO_OPT_PERVASIVE is enabled). This would allow
us to move that code in shadow.c
Is there any compelling advantage for shadow.c? Using a copy operation
every time the data change seems a bit contrary to the reason for
the new mechanism in the first place, namely to have a light-weight
means of sharing data.
The way I see it, the NTP data will be used by the nucleus clock and
timer subsystem, so several times for each timer tick, so having them on
an uncached memory will have a performance hit.
The copy, on the other hand, would take place over a non real-time
context, only once every update of NTP data, i.e. once every 10ms.
So, let us move it to shadow.c.
I see your point, but it has the disadvantage that the time spent
in the Linux kernel for the copy operations in the vsyscall is
increased -- which might affect the Linux domain, since this is
an optimised hot path. Naturally, in the absence of any quantitative
measurements, this is all just speculation, but if access to the global
semaphore heap is unchached only on ARM, we provide an unnecessary
optimisation for n-1 out of n architectures supported by Xenomai.
Having the time-keeping code in the Xenomai kernel benefit from NTP
corrections provided by the Linux side is a bit separate from the
ABI change, which would be the same irregardless of whether we
use a second copy for kernel-side NTP operations or not.
Exactly, the issue are distinct, the ABI change is a pure user-space
issue, so, should only be compiled if CONFIG_XENO_OPT_PERVASIVE is defined.
okay, that makes sense.
Would it
therefore make sense to restrict the data exchange to the global heap
semaphore, and add an architecture-specific hook for ARM
later on to generate an extra kernel space copy of the NTP data? The
Linux vsyscall time keeping information is architecture-specific, so
No. We will make it generic. Nothing arch specific is needed. We will
not copy the vsyscall time keeping information, we will copy the data
passed to update_vsyscall, which are the same on all architectures.
Having the possibility to use gettimeofday() without switching to
kernel mode is all about speed, and I don't see why re-using the
optimised data structures offered by the Linux kernel, together with the
already existing optimised read routines for this purpose
should not be an option for the Xenomai userland. But again, the
difference between the alternatives is hard to judge without
quantitative measurements. I'll maybe come back to this.
I thought we had been through this already and that we agreed. So, let
us make things clear, for once, and I will not be able to exchange much
further mails this afternoon.
We are not talking about speed. We already have speed:
clock_gettime(CLOCK_MONOTONIC) just reads the tsc, and converts the
result to a struct timespec, without a syscall, without even a division.
This is about as fast as it can be, and enough for 99% of real-time
applications. What we are talking about, is synchronizing
CLOCK_MONOTONIC and CLOCK_REALTIME with NTP corrections, without
sacrificing too much performance. Because, yes, we are going to
sacrifice performance, the computations using NTP data will be slower
than our current multiplication only conversion. This, for a very
specific kind of application.
Of the 5 architectures on which Xenomai is currently ported, only two
implement the update_vsyscall()
Re: [Xenomai-core] [PATCH] Add support for sharing kernel/userland data between Xenomai and Linux
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 hook for ARM later on to generate an extra kernel space copy of the NTP data? The Linux vsyscall time keeping information is architecture-specific, so No. We will make it generic. Nothing arch specific is needed. We will not copy the vsyscall time keeping information, we will copy the data passed to update_vsyscall, which are the same on all architectures. Having the possibility to use gettimeofday() without switching to kernel mode is all about speed, and I don't see why re-using the optimised data structures offered by the Linux kernel, together with the already existing optimised read routines for this purpose should not be an option for the Xenomai userland. But again, the difference between the alternatives is hard to judge without quantitative measurements. I'll maybe come back to this. I thought we had been through this already and that we agreed. So, let us make things clear, for once, and I will not be able to exchange much further mails this afternoon. well, the agreement was on 3- implement the nucleus callback for the I-pipe event which copies relevant data, and obviously we were taking different things to be the relevant data ;-) We are not talking about speed. We already have speed: clock_gettime(CLOCK_MONOTONIC) just reads the tsc, and converts the result to a struct timespec, without a syscall, without even a division. This is about as fast as it can be, and enough for 99% of real-time applications. What we are talking about, is synchronizing CLOCK_MONOTONIC and CLOCK_REALTIME with NTP corrections, without sacrificing too much performance. Because, yes, we are going to sacrifice performance, the computations using NTP data will be slower than our current multiplication only conversion. This, for a very specific kind of application. Of the 5 architectures on which Xenomai is currently ported, only two implement the update_vsyscall() function. That is a minority. And we are not interested in yet-another x86-only hack. What we want, because we want the same level of support for all architectures, that will be easier to maintain, is a solution as much generic as possible. Minimal #ifdefs, minimal architecture code. After all, this feature is only needed for a few specific applications, so, there is no reason for it to become a maintenance burden. Let us compare what we are talking about. My idea, is to get the I-pipe patches emit an event when update_vsyscall is called, and in the xenomai handler for this event, do the computations of the constants which will be used by the clock and timer operations until next update. This computation will happen with a xeno-seqlock locked irqs off. Actually, I thought there were some computations when starting this mail, but the computations we are talking about are in fact the copy of a handful of 32 bits and 64 bits variables. What you are talking about is, in the xenomai handler for the NTP I-pipe event, call an arch dependent hook which will copy the data from the x86 specific vsyscall_gtod_data structure. Unless I misunderstood you, there is no difference in terms of performance between the two implementations. And even if there was a difference, we are talking about code which is run as part of Linux timer handler, that is, when Xenomai tasks have relinquished the system. This only adds to the overhead of something that is already of some importance. there are indeed no calculations for AMD64, just for PPC. Since some architectures also require arch-specific hooks for gettimeofday() (albeit non of those with vsyscall and supported by Xenomai), I was trying to design a solution that could also cope with future archs that would require such a hook. But when easier maintainability is more important than optimal performance, I agree that the generic solution is by far better. So let's do it this way. Best, Wolfgang ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] cmd_write
Hi, I have been trying to test the functionality of the analogy_ni_pcimio driver on a NI6259 board. I am using a linux kernel 2.6.29.5 with the xenomai-head (rc5). Doing an a4l_sync_write to an analog output channel works fine. Now I am trying to use the cmd structure for writing to the same analog output channel, as done in the cmd_write progam (whose source I found in xenomai_root/src/util/analogy/cmd_write.c . But I am getting the error as indicated below. Any idea why this happens? My own programming gets the same error. Thanks a lot! -Stefan unix /usr/xenomai/bin/cmd_write -v -d analogy0 -s 1 -c 0 -S 1 cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 2 cmd_write: size to write = 2 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] cmd_write
Hi, Stefan Schaal wrote: Hi, I have been trying to test the functionality of the analogy_ni_pcimio driver on a NI6259 board. I am using a linux kernel 2.6.29.5 with the xenomai-head (rc5). Doing an a4l_sync_write to an analog output channel works fine. Now I am trying to use the cmd structure for writing to the same analog output channel, as done in the cmd_write progam (whose source I found in xenomai_root/src/util/analogy/cmd_write.c . But I am getting the error as indicated below. Any idea why this happens? My own programming gets the same error. Thanks a lot! -Stefan unix /usr/xenomai/bin/cmd_write -v -d analogy0 -s 1 -c 0 -S 1 cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 2 cmd_write: size to write = 2 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) Is there any kernel error messages ? Could you give us the last few lines of `dmesg` ? ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Build tests: analogy, blackfin, rtcan and nios2.
Hi Gilles, Gilles Chanteperdrix wrote: Hi, Since I started talking about it, I have run build tests fixing a few things here and there. The current status is this (still at the same place: http://sisyphus.hd.free.fr/~gilles/bx): * analogy: I have tried to disable some parts of analogy when compiling on machines without CONFIG_PCI, as compiling parts using PCI on a machine without PCI support, give various levels of warning and even errors depending on the architecture. Doing this, I stumbled across this compilation error: http://sisyphus.hd.free.fr/~gilles/bx/beagle/2.6.28-arm-none-linux-gnueabi-gcc-4.3.3/log.html#1 this is with CONFIG_NI_MIO, but without CONFIG_NI_MITE. So, Alex, could you: - fix that error, if this combination is supposed to make sense Yes it makes sense. I think the MITE is integrated into all PCI boards but the driver should work with the MITE disabled (one day, we could add the ISA boards). - fix the Kconfig/Makefile so that no PCI code is compiled if CONFIG_PCI is not set (I tried and do this myself, but better one who knows than 100 who have to search...). As I said, doing this result in various levels of success depending on the architecture. Ack. I will fix these problems as quickly as possible. * blackfin: I finally compiled blackfin! had to build a toolchain for that as the binary-only toolchain from analog.com uses glibc 2.8 and mine is 2.7. However, blackfin does not compile very well, as can be seen by the log: http://sisyphus.hd.free.fr/~gilles/bx/bf537-stamp/2.6.30-bfin-uclinux-gcc-4.1.2/log.html#1 It may happen that my toolchain is buggy or outdated though. * rtcan: on blackfin we seem to have a conflict with rtcan. The warning is about CAN_ERR_MASK, sure blackfin is a bit strange to define this in core headers which are included everywhere. This said, not prefixing a Xenomai symbol with something like XN seems to be asking for trouble. Wolfgang, do you think it would be possible to rename the symbols with such prefix? Or do you share some code with socket-can that you do not want to touch? * nios2: I am lacking some important file needed to even start to compile. Thanks in advance for your efforts. Regards. Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] cmd_write
dmesg: Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: b_status=0002 m1_status=80a8 [15619.322973] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: timed out waiting for dma load -Stefan On Dec 22, 2009, at 16:52, Alexis Berlemont wrote: Hi, Stefan Schaal wrote: Hi, I have been trying to test the functionality of the analogy_ni_pcimio driver on a NI6259 board. I am using a linux kernel 2.6.29.5 with the xenomai-head (rc5). Doing an a4l_sync_write to an analog output channel works fine. Now I am trying to use the cmd structure for writing to the same analog output channel, as done in the cmd_write progam (whose source I found in xenomai_root/src/util/analogy/cmd_write.c . But I am getting the error as indicated below. Any idea why this happens? My own programming gets the same error. Thanks a lot! -Stefan unix /usr/xenomai/bin/cmd_write -v -d analogy0 -s 1 -c 0 -S 1 cmd_write: device analogy0 opened (fd=0) cmd_write: basic descriptor retrieved subdevices count = 14 read subdevice index = 0 write subdevice index = 1 cmd_write: complex descriptor retrieved cmd_write: channel 0 ranges count = 3 range's size = 16 (bits) cmd_write: scan size = 2 cmd_write: size to write = 2 cmd_write: command successfully sent cmd_write: triggering failed (ret=-32) Is there any kernel error messages ? Could you give us the last few lines of `dmesg` ? ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core Alexis. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
