Re: [Xenomai-core] Xenomai v2.0
Philippe Gerum wrote: The first stable release of the former fusion effort is now available for download. I have not much more to say, except to thank to everyone involved with this tireless work since 2001. v2.0 is an important milestone in the life of this project, and as such, it paves the way to the seamlessly integrated real-time framework for Linux we strive at building. Time to make some noise, I guess ;): What about an article at LinuxDevices e.g.? Further suggestions? Once there are some text modules they could easily be reused... But before starting: should we wait for the new website? When will it likely be finished? 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] Xenomai v2.0
Jan Kiszka wrote: Philippe Gerum wrote: The first stable release of the former fusion effort is now available for download. I have not much more to say, except to thank to everyone involved with this tireless work since 2001. v2.0 is an important milestone in the life of this project, and as such, it paves the way to the seamlessly integrated real-time framework for Linux we strive at building. Time to make some noise, I guess ;): What about an article at LinuxDevices e.g.? Further suggestions? Once there are some text modules they could easily be reused... LWN ? /.? But before starting: should we wait for the new website? When will it likely be finished? I would argue in favor of waiting for the new website. The current xemai.org portal is a bit, well, rough for newcomers :-) -- Stephane ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH: 0/3] powerpc merge
Heikki Lindholm wrote: Merge 32- and 64-bit powerpc architectures into a common powerpc arch in anticipation of the similar merge happening in linux kernel (possible in 2.6.15). Amount of shared code between 32- and 64-bit ppc is substantial and I don't see anything changing that. These patches will simplify maintenance. In case the mailing list rejects the largish attachments I'll see if I can use the patch tracker in gna instead. Ok, thanks (patches made their way). Will merge in the next-to-come 2.1 branch that should appear this WE. I have made progress separating the kernel and user-space supports, and compiling the whole Xenomai modules inside the kernel, so basically we just need to wait for the user-space support to be compilable anew for the branch to appear. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] problem and solution with adeos-ipipe-2.6.13-ppc-1.0-03.patch
Fillod Stephane wrote: Hi, The adeos-ipipe-2.6.13-ppc-1.0-03.patch file in Xenomai-2.0 dist appears to be broken. The unified diff format is wrong on include/asm-ppc/ipipe.h, which breaks include/asm-ppc/mmu_context.h. I've found the problem while applying the patch on a Linux 2.6.13 kernel. Line 1664 (no pun :), instead of @@ -0,1 +1,178 @@, the following solves the problem here: @@ -0,0 +1,177 @@ Gahh... Ok. Does somebody else encountered the problem? For the record, here is for 2.6.13-ppc-1.0-03 the result of klatency, with only calibrator as a load generator. KLATENCY with load: RTH|-lat min|-lat avg|-lat max|-overrun| RTS| -7350| -5715|6420| 0|00:03:17 1.0-00 RTS| -6150| -4384| 12180| 0|00:03:13 1.0-01 RTS| -6150| -4183| 12480| 0|00:03:38 1.0-02 RTS| -6120| -4447|8370| 0|00:03:47 1.0-02+ RTS| -6210| -5381| 12390| 0|00:03:38 1.0-03 Ok, I need to check some changes between -02 and -03 before sending -04 out. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [bug-reminder] user/kernel space header deps
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, just to avoid that this issue got lost during the migration to Xenomai: It's still not possible to compile a C++ POSIX program with CFLAGS obtained via xeno-config --posix-ldflags. This is due to the fact that low-level, C++-incompatible headers get included in that case. Moreover, the same scenarion works for native skin programs only by chance at the moment. On the long term, a clear separation between types, defines, function prototypes, etc. needed for the user API on the one and for core compilation on the other side is required. Without duplicating definitions and ABI information, otherwise this would be an absolute nightmare. Suggestions welcome. To pick up this issue again (as it's biting me more and more...): What precisely prevents us at the moment from removing the -Ikernel-headers from all userspace build steps, both Xenomai's own libraries as well as external rt-applications? Because a few things like asm/atomic.h and linux/bitops.h are wanted from the target header base for compiling some bits of user-space stuff. Not pretty, but currently needed. This is probably what needs to be fixed, in which case the -I directive would become useless in the same move. Gilles explained to me that at least asm/atomic.h is used by certain parts like UVM (or only UVM?), and that including this header directly from /usr/include fails on Red Hat/Fedora boxes. Are there any further problems? At least on my SuSE 10 everything still compiles fine (including UVM) when I remove the kernel headers from XENO_USER_CFLAGS in configure.in. It's not an issue with such inclusion failing/passing, it's just that it would be incorrect to include your host distro's headers for that purpose, since what we need here is the _target_ stuff. The fact that it works on your box is just because 1) your host == your target arch, and 2) your host header base does not seem to implement guards preventing the use of kernel headers in user-space context. In cross compilation context, such inclusion would simply break the build, since it expects the target architecture headers to be used, not the host's ones. I see, so the problem is the pre-set link of /usr/include/asm to /usr/include/asm-i386 in my case. Anyway, it seems that really few code is involved so that it should be possible to find either related headers in the standard libc or copy that few atomic ops to Xenomai's arch-dependent includes. Yes, fixing that need is the way to go. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH: 3/3] powerpc merge
Alter makefiles to accomodate the new powerpc arch and forget the old
ppc and ppc64 ones. This is based on guesswork and will probably need
some clean(s)ing up by somebody more knowledgeable on the Xenomai
makefile system. The problem is that the makefiles need to map three
kernel archs (ppc,ppc64 and the future powerpc) to one xenomai arch
(powerpc).
-- Heikki Lindholm
diff -Nru --exclude=.svn xenomai-orig/arch/GNUmakefile.am
xenomai-devel/arch/GNUmakefile.am
--- xenomai-orig/arch/GNUmakefile.am2005-10-11 10:32:31.0 +0300
+++ xenomai-devel/arch/GNUmakefile.am 2005-10-23 11:32:19.0 +0300
@@ -3,10 +3,10 @@
endif
if CONFIG_PPC64
-ARCHDIR = ppc64
+ARCHDIR = powerpc
else
if CONFIG_PPC
-ARCHDIR = ppc
+ARCHDIR = powerpc
endif
endif
diff -Nru --exclude=.svn xenomai-orig/config/kconfig/Makefile.kconfig
xenomai-devel/config/kconfig/Makefile.kconfig
--- xenomai-orig/config/kconfig/Makefile.kconfig2005-10-11
10:32:11.0 +0300
+++ xenomai-devel/config/kconfig/Makefile.kconfig 2005-10-23
15:58:12.0 +0300
@@ -32,33 +32,40 @@
endif
endif
+ifeq ($(ARCH), ppc)
+ XENO_ARCH := powerpc
+endif
+ifeq ($(ARCH), ppc64)
+ XENO_ARCH := powerpc
+endif
+
LXDIALOG_OBJS := lxdialog/checklist.o lxdialog/menubox.o \
lxdialog/textbox.o lxdialog/yesno.o lxdialog/inputbox.o \
lxdialog/util.o lxdialog/lxdialog.o lxdialog/msgbox.o
xconfig: qconf
- @./qconf $(srctree)/arch/$(ARCH)/Kconfig
+ @./qconf $(srctree)/arch/$(XENO_ARCH)/Kconfig
gconfig: gconf
- @./gconf $(srctree)/arch/$(ARCH)/Kconfig
+ @./gconf $(srctree)/arch/$(XENO_ARCH)/Kconfig
menuconfig mconfig: mconf
- @./mconf $(srctree)/arch/$(ARCH)/Kconfig
+ @./mconf $(srctree)/arch/$(XENO_ARCH)/Kconfig
config: conf
- @./conf $(srctree)/arch/$(ARCH)/Kconfig
+ @./conf $(srctree)/arch/$(XENO_ARCH)/Kconfig
oldconfig: conf
- @./conf -o $(srctree)/arch/$(ARCH)/Kconfig
+ @./conf -o $(srctree)/arch/$(XENO_ARCH)/Kconfig
qconf: .qtinst
- $(MAKE) -f $(srcdir)/Makefile.kconfig qbuild srctree=$(srctree)
ARCH=$(ARCH)
+ $(MAKE) -f $(srcdir)/Makefile.kconfig qbuild srctree=$(srctree)
ARCH=$(ARCH) XENO_ARCH=$(XENO_ARCH)
qbuild: qconf.o kconfig_load.o libkconfig.so
$(CXX) -o qconf $^ -Wl,-rpath,$(this_dir) -L$(QTDIR)/lib
-Wl,-rpath,$(QTDIR)/lib -l$(QTLIB) -ldl
gconf: .gtkinst
- $(MAKE) -f $(srcdir)/Makefile.kconfig gbuild srctree=$(srctree)
ARCH=$(ARCH)
+ $(MAKE) -f $(srcdir)/Makefile.kconfig gbuild srctree=$(srctree)
ARCH=$(ARCH) XENO_ARCH=$(XENO_ARCH)
gbuild: gconf.o kconfig_load.o libkconfig.so
$(CC) -o gconf $^ -Wl,-rpath,$(this_dir) $(GLIBS)
diff -Nru --exclude=.svn xenomai-orig/configure.in xenomai-devel/configure.in
--- xenomai-orig/configure.in 2005-10-23 11:00:14.0 +0300
+++ xenomai-devel/configure.in 2005-10-23 15:58:41.0 +0300
@@ -48,21 +48,25 @@
case $host in
i*86*-*)
XENO_TARGET_ARCH=i386
+ XENO_KERNEL_TARGET_ARCH=i386
wanted_kernel_arch=CONFIG_X86
arch_have_sim=y
;;
powerpc-*|ppc-*)
- XENO_TARGET_ARCH=ppc
+ XENO_TARGET_ARCH=powerpc
+ XENO_KERNEL_TARGET_ARCH=ppc
wanted_kernel_arch=CONFIG_PPC
arch_have_sim=y
;;
powerpc64-*|ppc64-*)
- XENO_TARGET_ARCH=ppc64
+ XENO_TARGET_ARCH=powerpc
+ XENO_KERNEL_TARGET_ARCH=ppc64
wanted_kernel_arch=CONFIG_PPC64
arch_have_sim=y
;;
ia64-*)
XENO_TARGET_ARCH=ia64
+ XENO_KERNEL_TARGET_ARCH=ia64
wanted_kernel_arch=CONFIG_IA64
arch_have_sim=y
;;
@@ -226,7 +230,7 @@
AC_MSG_CHECKING([for interrupt pipeline extension])
if test -r $XENO_LINUX_SRCDIR/include/linux/ipipe.h; then
- v=`grep '^#define.*IPIPE_ARCH_STRING.*'
$XENO_LINUX_SRCDIR/include/asm-$XENO_TARGET_ARCH/ipipe.h|sed -e
's,.*\(.*\)$,\1,'`
+ v=`grep '^#define.*IPIPE_ARCH_STRING.*'
$XENO_LINUX_SRCDIR/include/asm-$XENO_KERNEL_TARGET_ARCH/ipipe.h|sed -e
's,.*\(.*\)$,\1,'`
AC_MSG_RESULT([Adeos newgen (I-pipe $v)])
if test x${CONFIG_IPIPE} = x; then
AC_MSG_ERROR([Please activate the Adeos support in $XENO_LINUX_DIR and
rebuild your kernel])
@@ -235,7 +239,7 @@
AC_MSG_ERROR([Please re-patch your kernel with the Adeos support])
fi
elif test -r $XENO_LINUX_SRCDIR/include/linux/adeos.h; then
- v=`grep '^#define.*ADEOS_ARCH_STRING.*'
$XENO_LINUX_SRCDIR/include/asm-$XENO_TARGET_ARCH/adeos.h|sed -e
's,.*\(.*\)$,\1,'`
+ v=`grep '^#define.*ADEOS_ARCH_STRING.*'
$XENO_LINUX_SRCDIR/include/asm-$XENO_KERNEL_TARGET_ARCH/adeos.h|sed -e
's,.*\(.*\)$,\1,'`
AC_MSG_RESULT([Adeos oldgen ($v)])
if test x${CONFIG_ADEOS_CORE} = x; then
AC_MSG_ERROR([Please activate the Adeos support in $XENO_LINUX_DIR and
rebuild your kernel])
@@ -309,7 +313,7 @@
HOST_EXTRACFLAGS += -DXENO_CFLAGS=\\$(CC) \$(CFLAGS)\
EOF
-CC=$CC make -s -C
RE: [Xenomai-core] Xenomai v2.0
Jan Kiszka wrote: Philippe Gerum wrote: The first stable release of the former fusion effort is now available for download. I have not much more to say, except to thank to everyone involved with this tireless work since 2001. v2.0 is an important milestone in the life of this project, and as such, it paves the way to the seamlessly integrated real-time framework for Linux we strive at building. Time to make some noise, I guess ;): What about an article at LinuxDevices e.g.? Further suggestions? Once there are some text modules they could easily be reused... LWN ? /.? But before starting: should we wait for the new website? When will it likely be finished? I would argue in favor of waiting for the new website. The current xemai.org portal is a bit, well, rough for newcomers :-) -- Stephane
Re: [Xenomai-core] [PATCH: 0/3] powerpc merge
Heikki Lindholm wrote: Merge 32- and 64-bit powerpc architectures into a common powerpc arch in anticipation of the similar merge happening in linux kernel (possible in 2.6.15). Amount of shared code between 32- and 64-bit ppc is substantial and I don't see anything changing that. These patches will simplify maintenance. In case the mailing list rejects the largish attachments I'll see if I can use the patch tracker in gna instead. Ok, thanks (patches made their way). Will merge in the next-to-come 2.1 branch that should appear this WE. I have made progress separating the kernel and user-space supports, and compiling the whole Xenomai modules inside the kernel, so basically we just need to wait for the user-space support to be compilable anew for the branch to appear. -- Philippe.
Re: [Xenomai-core] problem and solution with adeos-ipipe-2.6.13-ppc-1.0-03.patch
Fillod Stephane wrote: Hi, The adeos-ipipe-2.6.13-ppc-1.0-03.patch file in Xenomai-2.0 dist appears to be broken. The unified diff format is wrong on include/asm-ppc/ipipe.h, which breaks include/asm-ppc/mmu_context.h. I've found the problem while applying the patch on a Linux 2.6.13 kernel. Line 1664 (no pun :), instead of @@ -0,1 +1,178 @@, the following solves the problem here: @@ -0,0 +1,177 @@ Gahh... Ok. Does somebody else encountered the problem? For the record, here is for 2.6.13-ppc-1.0-03 the result of klatency, with only calibrator as a load generator. KLATENCY with load: RTH|-lat min|-lat avg|-lat max|-overrun| RTS| -7350| -5715|6420| 0|00:03:17 1.0-00 RTS| -6150| -4384| 12180| 0|00:03:13 1.0-01 RTS| -6150| -4183| 12480| 0|00:03:38 1.0-02 RTS| -6120| -4447|8370| 0|00:03:47 1.0-02+ RTS| -6210| -5381| 12390| 0|00:03:38 1.0-03 Ok, I need to check some changes between -02 and -03 before sending -04 out. -- Philippe.
Re: [Xenomai-core] problem and solution with adeos-ipipe-2.6.13-ppc-1.0-03.patch
Aristeu Sergio Rozanski Filho wrote: Hi, The adeos-ipipe-2.6.13-ppc-1.0-03.patch file in Xenomai-2.0 dist appears to be broken. The unified diff format is wrong on include/asm-ppc/ipipe.h, which breaks include/asm-ppc/mmu_context.h. I've found the problem while applying the patch on a Linux 2.6.13 kernel. Line 1664 (no pun :), instead of @@ -0,1 +1,178 @@, the following solves the problem here: @@ -0,0 +1,177 @@ Does somebody else encountered the problem? I did. maybe it's a good reason for 2.01? Maybe as we need to put perfectly buildable stuff on-line before making some noise as Jan's put it. Time for discovering other rough edges before 2.0.1 is rolled out, I guess. -- Philippe.
Re: [Xenomai-core] [bug-reminder] user/kernel space header deps
Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Hi, just to avoid that this issue got lost during the migration to Xenomai: It's still not possible to compile a C++ POSIX program with CFLAGS obtained via xeno-config --posix-ldflags. This is due to the fact that low-level, C++-incompatible headers get included in that case. Moreover, the same scenarion works for native skin programs only by chance at the moment. On the long term, a clear separation between types, defines, function prototypes, etc. needed for the user API on the one and for core compilation on the other side is required. Without duplicating definitions and ABI information, otherwise this would be an absolute nightmare. Suggestions welcome. To pick up this issue again (as it's biting me more and more...): What precisely prevents us at the moment from removing the -Ikernel-headers from all userspace build steps, both Xenomai's own libraries as well as external rt-applications? Because a few things like asm/atomic.h and linux/bitops.h are wanted from the target header base for compiling some bits of user-space stuff. Not pretty, but currently needed. This is probably what needs to be fixed, in which case the -I directive would become useless in the same move. Gilles explained to me that at least asm/atomic.h is used by certain parts like UVM (or only UVM?), and that including this header directly from /usr/include fails on Red Hat/Fedora boxes. Are there any further problems? At least on my SuSE 10 everything still compiles fine (including UVM) when I remove the kernel headers from XENO_USER_CFLAGS in configure.in. It's not an issue with such inclusion failing/passing, it's just that it would be incorrect to include your host distro's headers for that purpose, since what we need here is the _target_ stuff. The fact that it works on your box is just because 1) your host == your target arch, and 2) your host header base does not seem to implement guards preventing the use of kernel headers in user-space context. In cross compilation context, such inclusion would simply break the build, since it expects the target architecture headers to be used, not the host's ones. I see, so the problem is the pre-set link of /usr/include/asm to /usr/include/asm-i386 in my case. Anyway, it seems that really few code is involved so that it should be possible to find either related headers in the standard libc or copy that few atomic ops to Xenomai's arch-dependent includes. Jan signature.asc Description: OpenPGP digital signature
