[Xenomai-core] [PATCH] Mask signals in rt_print:printer_loop()
common/rt_print: Use sigfillset to actually mask all signals for
logging thread. Fixes commit a6dceeb9.
Signed-off-by: Paul Janzen
---
src/skins/common/rt_print.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/skins/common/rt_print.c b/src/skins/common/rt_print.c
index e1c828a..272a4ba 100644
--- a/src/skins/common/rt_print.c
+++ b/src/skins/common/rt_print.c
@@ -615,7 +615,7 @@ static void *printer_loop(void *arg)
{
sigset_t mask;
- sigemptyset(&mask);
+ sigfillset(&mask);
pthread_sigmask(SIG_BLOCK, &mask, NULL);
while (1) {
--
1.7.1
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] debian/prepare-patch
Now that Debian has gone "stable" with Lenny, I've been updating some of my
local repositories - The current debian/rule set produces a horribly broken
patch for 2.6.28 (on x86), and probably other kernels. The attached patch
goes some way to resolving this problem for trunk and probably needs to be
applied to the v2.4.x branch so that it can be picke up by the Debian team.
Regards, Paul.
Index: debian/prepare-patch.sh
===
--- debian/prepare-patch.sh (revision 4639)
+++ debian/prepare-patch.sh (working copy)
@@ -74,12 +74,11 @@ generate_patch() {
}
diff_addons() {
-lines=`(echo ; echo ; cat $xenomai_root/scripts/Kconfig.frag) | wc -l`
+lines=`cat $xenomai_root/scripts/Kconfig.frag | wc -l`
-echo "--- linux/arch/$linux_arch/Kconfig 1970-01-01 01:00:00.0 +0100" >> $patch_file
-echo "+++ linux-patched/arch/$linux_arch/Kconfig 2007-03-06 17:55:58.0 +" >> $patch_file
-echo "@@ -40,2 +40,$lines @@" >> $patch_file
-echo " source \"init/Kconfig\"" >> $patch_file
+echo "--- linux/init/Kconfig 1970-01-01 01:00:00.0 +0100" >> $patch_file
+echo "+++ linux-patched/init/Kconfig 2007-03-06 17:55:58.0 +" >> $patch_file
+echo "@@ -950,0 +950,$lines @@" >> $patch_file
sed -e "s,@LINUX_ARCH@,$linux_arch,g" $xenomai_root/scripts/Kconfig.frag | sed 's/^/+/' >> $patch_file
echo " " >> $patch_file
}
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] SMP build failure (2.6.28)
On Thursday 12 February 2009, Gilles Chanteperdrix wrote: > Paul wrote: > > Patching a 2.6.28.2 with the relevant patch in trunk, using a config with > > SMP enabled resulted in: > > > > LD kernel/xenomai/arch/built-in.o > > CC kernel/xenomai/nucleus/heap.o > > In file included from include/xenomai/nucleus/pod.h:34, > > from kernel/xenomai/nucleus/heap.c:66: > > include/xenomai/nucleus/sched.h: In function ‘xnsched_self_resched_p’: > > include/xenomai/nucleus/sched.h:171: error: ‘nkpod’ undeclared (first use > > in this function) > > include/xenomai/nucleus/sched.h:171: error: (Each undeclared identifier > > is reported only once > > include/xenomai/nucleus/sched.h:171: error: for each function it appears > > in.) make[3]: *** [kernel/xenomai/nucleus/heap.o] Error 1 > > > > > > Digging in to the nucleus/sched.h and nucleus/pod.h headers, there > > appears to be a circular dependency around nkpod_struct - This only hits > > home with CONFIG_SMP defined. > > There must be some other option triggering the bug, because I run trunk > with 2.6.28 on an SMP x86(_64). Attached, tarball of the two configs - One for SMP, the other, UP, both for 32Bit. Looking at the changelog, I see xnsched_self_resched_p was introduced in r4611 - Reverting the change allows compilation to progress... Regards, Paul. configs.bz2 Description: BZip2 compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] SMP build failure (2.6.28)
Patching a 2.6.28.2 with the relevant patch in trunk, using a config with SMP enabled resulted in: LD kernel/xenomai/arch/built-in.o CC kernel/xenomai/nucleus/heap.o In file included from include/xenomai/nucleus/pod.h:34, from kernel/xenomai/nucleus/heap.c:66: include/xenomai/nucleus/sched.h: In function ‘xnsched_self_resched_p’: include/xenomai/nucleus/sched.h:171: error: ‘nkpod’ undeclared (first use in this function) include/xenomai/nucleus/sched.h:171: error: (Each undeclared identifier is reported only once include/xenomai/nucleus/sched.h:171: error: for each function it appears in.) make[3]: *** [kernel/xenomai/nucleus/heap.o] Error 1 Digging in to the nucleus/sched.h and nucleus/pod.h headers, there appears to be a circular dependency around nkpod_struct - This only hits home with CONFIG_SMP defined. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] FPU support
Hi Giles On Tuesday 27 January 2009, Gilles Chanteperdrix wrote: > So, the question is: are there people around who either: > - need FPU support for kernel-space real-time threads; > - do not want to pay the price of a trap when using the FPU in user-space. One application that I work on uses floating point math in kernel space, but it is a constant source of problems - Being forced to migrate to user space would be a welcome move.. The only question is how much of an overhead does the trap incur ? Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Allow Debian tools to cross compile
Attached, a small patch for debian/rules to allow dpkg-cross to cross-compile binary packages. Tested on a AMD64 host compiling powerpc packages, and no unpleasant suprises found. Regards, Paul. Index: debian/rules === --- debian/rules (revision 4519) +++ debian/rules (working copy) @@ -8,6 +8,8 @@ DEB_HOST_GNU_CPU ?= $(shell dpkg-architecture -qDEB_HOST_GNU_CPU) DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) +DEB_HOST_GNU_TYPE=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +DEB_BUILD_GNU_TYPE=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) ifeq ($(DEB_HOST_ARCH), i386) # Note: Would like to use --includedir=/usr/include/xenomai, but @@ -35,7 +37,13 @@ ifeq ($(DEB_HOST_ARCH), arm) endif CONFIG_OPTS += --prefix=/usr \ --includedir=/usr/include/xenomai \ - --mandir=/usr/share/man + --mandir=/usr/share/man \ + +ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) + CONFIG_OPTS += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) +else + CONFIG_OPTS += --build $(DEB_BUILD_GNU_TYPE) +endif build: build-arch build-indep ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Minor correction to debian/control
Reviewing and updating one of my systems here, I noticed a copy/paste error
in the debian/control - The short description is the same for both lib and
dev packages. The $trivial patch attached addresses this. Both the 2.4.x
branch and trunk suffer from the same error.
Regards, Paul.
Index: debian/control
===
--- debian/control (revision 4493)
+++ debian/control (working copy)
@@ -52,7 +52,7 @@ Depends: ${shlibs:Depends}
Suggests: linux-patch-xenomai, xenomai-doc
Replaces: xenomai
Conflicts: xenomai
-Description: Headers and static libs for Xenomai
+Description: Shared libraries for Xenomai
Xenomai is a real-time development framework cooperating with the Linux
kernel in order to provide a pervasive, interface-agnostic, hard real-time
support to user-space applications, seamlessly integrated into the GNU/Linux
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Script marking
Hi Giles First, sorry about not jumping in on some of the other threads about Debian and packaging... On Friday 29 February 2008 19:50, Gilles Chanteperdrix wrote: > Roland Stigge wrote: > > Gilles Chanteperdrix wrote: > > >> Further, I updated the package in Debian with the suggested changes. > > > > > > We trust you, please send patches. > > > > The attached patch (and the latest version of it) can also always be > > found at the Debian developer's package page for Xenomai at > > http://packages.qa.debian.org/x/xenomai.html . > > > > It applies to the latest Xenomai release (currently 2.4.2), and assumes > > that there is _no_ debian/ directory in the original source tree (as > > discussed beforehand - Debian maintains the complete debian/* hierarchy > > completely - for further questions just ask). > > Hi Paul, > > Is it Ok for you to replace the repository debian directory current > contents with the debian directory as provided by Roland ? Or will it > break things on your side ? I have no problem with Roland's changes, it won't break anything I do. The relevant wiki page will need to be updated to reflect the extra packages that are generated, but that is a minor detail. On a personal level, I would like to see a debian/ structure retained within SVN - This simplifies test builds and allows changes (such as merged x86 trees) to be tackled before (Debian) releases are made. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Buildbot is back (and reporting errors)
Hi Niklaus
On Sunday 23 December 2007 16:47, Niklaus Giger wrote:
> > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c: In
> > function 'lbmStartIO':
> > /home/buildbot/slave/i386_f/linux-2.6-xenomai/fs/jfs/jfs_logmgr.c:2165:
> > error: too many arguments to function 'lbmIODone'
> > /var/buildbot/slave/ppc_f/linux-2.6-xenomai/drivers/net/via-rhine.c:44:1:
> > error: unterminated #ifndef make[3]: *** [drivers/net/via-rhine.o] Error
Attached patch resolves the two above errors - I too fell foul of them with an
unpatched build (along with a couple in the USB code).
> > /home/buildbot/slave/hcu3_f/linux-2.6-xenomai/arch/ppc/kernel/smp.c:341:
> > error: implicit declaration of function 'get_paca'
This one is from the Xenomai patch - get_paca is found in asm-powerpc/paca.h
which is conditionally included when CONFIG_PPC64 is defined. I suspect line
340 should read:
#if defined(CONFIG_IPIPE) && defined(CONFIG_PPC64)
It bit me at line 549 in arch/powerpc/kernel/smp.c...
Regards, Paul.
index 0041343..8f30c85 100644
--- a/drivers/net/via-rhine.c
+++ b/drivers/net/via-rhine.c
@@ -41,7 +41,6 @@
static int debug = 1; /* 1 normal messages, 0 quiet .. 7 verbose. */
static int max_interrupt_work = 20;
-#ifndef PKT_ALIGN
/* Set the copy breakpoint for the copy-only-tiny-frames scheme.
Setting to > 1518 effectively disables this feature. */
#if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
index b1d1926..45dc960 100644
--- a/drivers/usb/host/ehci-au1xxx.c
+++ b/drivers/usb/host/ehci-au1xxx.c
@@ -221,8 +221,8 @@ static const struct hc_driver ehci_au1xxx_hc_driver = {
.hub_status_data = ehci_hub_status_data,
.hub_control = ehci_hub_control,
#ifdef CONFIG_PM
- .hub_suspend = ehci_hub_suspend,
- .hub_resume = ehci_hub_resume,
+ .bus_suspend = ehci_bus_suspend,
+ .bus_resume = ehci_bus_resume,
#endif
};
index 463650e..c6f8599 100644
--- a/drivers/usb/host/ehci-ppc-of.c
+++ b/drivers/usb/host/ehci-ppc-of.c
@@ -73,8 +73,8 @@ static const struct hc_driver ehci_ppc_of_hc_driver = {
.hub_status_data = ehci_hub_status_data,
.hub_control = ehci_hub_control,
#ifdef CONFIG_PM
- .hub_suspend = ehci_hub_suspend,
- .hub_resume = ehci_hub_resume,
+ .bus_suspend = ehci_bus_suspend,
+ .bus_resume = ehci_bus_resume,
#endif
};
index 4f99b0e..1d40843 100644
--- a/drivers/usb/host/ehci-ppc-soc.c
+++ b/drivers/usb/host/ehci-ppc-soc.c
@@ -161,8 +161,8 @@ static const struct hc_driver ehci_ppc_soc_hc_driver = {
.hub_status_data = ehci_hub_status_data,
.hub_control = ehci_hub_control,
#ifdef CONFIG_PM
- .hub_suspend = ehci_hub_suspend,
- .hub_resume = ehci_hub_resume,
+ .bus_suspend = ehci_bus_suspend,
+ .bus_resume = ehci_bus_resume,
#endif
};
index 57c3b8a..59dbc5c 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
@@ -2162,7 +2162,7 @@ static void lbmStartIO(struct lbuf * bp)
/* check if journaling to disk has been disabled */
if (log->no_integrity) {
bio->bi_size = 0;
- lbmIODone(bio, 0, 0);
+ lbmIODone(bio, 0);
} else {
submit_bio(WRITE_SYNC, bio);
INCREMENT(lmStat.submitted);
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] trivial native mutex doc tweak.
Attached, trivial patch for native rt_mutex_acquire function documentation. The reference to deprecated (and undocumented) rt_mutex_lock() & rt_mutex_release() is a little confusing. Also updated the code snippets to match. Regards, Paul. Index: ksrc/skins/native/mutex.c === --- ksrc/skins/native/mutex.c (revision 3229) +++ ksrc/skins/native/mutex.c (working copy) @@ -297,7 +297,7 @@ int rt_mutex_delete(RT_MUTEX *mutex) * recursive and implement the priority inheritance protocol. * * Since a nested locking count is maintained for the current owner, - * rt_mutex_lock() and rt_mutex_unlock() must be used in pairs. + * rt_mutex_acquire() and rt_mutex_release() must be used in pairs. * * Tasks pend on mutexes by priority order. * Index: ksrc/skins/native/snippets/mutex.c === --- ksrc/skins/native/snippets/mutex.c (revision 3229) +++ ksrc/skins/native/snippets/mutex.c (working copy) @@ -17,11 +17,11 @@ int main (int argc, char *argv[]) /* Now, grab the mutex lock, run the critical section, then release the lock: */ -rt_mutex_lock(&mutex_desc,TM_INFINITE); +rt_mutex_acquire(&mutex_desc,TM_INFINITE); /* ... Critical section ... */ -rt_mutex_unlock(&mutex_desc); +rt_mutex_release(&mutex_desc); /* ... */ } Index: ksrc/skins/native/snippets/cond_var.c === --- ksrc/skins/native/snippets/cond_var.c (revision 3229) +++ ksrc/skins/native/snippets/cond_var.c (working copy) @@ -21,12 +21,12 @@ void foo (void) /* Now, wait for some task to post the shared event... */ -rt_mutex_lock(&mutex_desc,TM_INFINITE); +rt_mutex_acquire(&mutex_desc,TM_INFINITE); while (!shared_event && !err) err = rt_cond_wait(&cond_desc,&mutex_desc,TM_INFINITE); -rt_mutex_unlock(&mutex_desc); +rt_mutex_release(&mutex_desc); /* ... */ } @@ -38,12 +38,12 @@ void bar (void) /* Post the shared event. */ -rt_mutex_lock(&mutex_desc,TM_INFINITE); +rt_mutex_acquire(&mutex_desc,TM_INFINITE); shared_event = 1; rt_cond_signal(&cond_desc); -rt_mutex_unlock(&mutex_desc); +rt_mutex_release(&mutex_desc); /* ... */ } ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6
On Wednesday 14 November 2007 23:13, Leopold Palomo Avellaneda wrote: > A Dimecres 14 Novembre 2007, Paul va escriure: > > On Wednesday 14 November 2007 16:37, Paul wrote: > > > I'm right in the middle of looking at the packaging scripts, so expect > > > a patch within the next few days. > > > > Attached, one patch for the Debian rules. The debian/changelog version > > will need to be bumped up to 2.4.0-1 once we get out of the -rc phase. > > I'll submit a trivial patch at that point and build a set of i386 & amd64 > > packages. > > Thank's, > > the patch has worked well for me (amd64), however I should say that the > packages are not lintian free. I can mention: > > package xenomai-dev > --- > W: xenomai-dev: symlink-is-self-recursive > usr/include/xenomai/asm-sim/xenomai . > N: > N: The symbolic link is recursive to a higher directory of the symlink > N: itself. This means, that you can infinitely chdir with this symlink. > N: This is usually not okay, but sometimes wanted behaviour. > N: > W: xenomai-dev: symlink-is-self-recursive usr/include/xenomai/asm-sim/asm . > W: xenomai-dev: symlink-is-self-recursive > usr/include/xenomai/asm-x86/xenomai . > W: xenomai-dev: symlink-is-self-recursive usr/include/xenomai/xenomai . > W: xenomai-dev: symlink-is-self-recursive > usr/include/xenomai/asm-generic/xenomai . I'm aware of the recursion - Removing the symlinks in question could be tackled in automake, but may well break for other people. > package xenomai > --- > E: xenomai: shell-script-fails-syntax-check ./usr/bin/xeno-test > W: xenomai: > executable-not-elf-or-script ./usr/share/xenomai/testsuite/cyclic/run > W: xenomai: > executable-not-elf-or-script ./usr/share/xenomai/testsuite/irqbench/run > W: xenomai: > executable-not-elf-or-script ./usr/share/xenomai/testsuite/switchtest/run > W: xenomai: > executable-not-elf-or-script ./usr/share/xenomai/testsuite/latency/run > W: xenomai: > executable-not-elf-or-script ./usr/share/xenomai/testsuite/clocktest/run > W: xenomai: > executable-not-elf-or-script ./usr/share/xenomai/testsuite/switchbench/run > W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libpsos.so.0.0.0 > usr/lib/libpsos.so > W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/librtai.so.0.0.0 > usr/lib/librtai.so > W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libnative.so.1.0.0 > usr/lib/libnative.so > W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libuitron.so.0.0.0 > usr/lib/libuitron.so > W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/librtdm.so.1.0.0 > usr/lib/librtdm.so > W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libpthread_rt.so.1.0.0 > usr/lib/libpthread_rt.so > W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libvxworks.so.1.0.0 > usr/lib/libvxworks.so > W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/librtdk.so.0.0.0 > usr/lib/librtdk.so > W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libvrtx.so.0.0.0 > usr/lib/libvrtx.so The exec status & symlinks, I feel are outside my remit, as is the libtool versioning.. > E: xenomai: postinst-must-call-ldconfig usr/lib/librtdk.so.0.0.0 > W: xenomai: postrm-should-call-ldconfig usr/lib/librtdk.so.0.0.0 Fixed with the new patch. > E: xenomai: description-starts-with-package-name > W: xenomai: description-synopsis-might-not-be-phrased-properly Is it really a problem - I don't feel it is. > W: xenomai: package-name-doesnt-match-sonames libpsos0 librtdm1 libvxworks1 > libuitron0 librtdk0 librtai0 libnative1 libvrtx0 libpthread-rt1 Current Debian policy appears to be moving towards individual packages for each library - Could follow suit, maybe if/when Xenomai is accepted into Debian. > lintian linux-patch-xenomai_2.4.0-0+rc6_all.deb > internal error: syntax error in section 1 after the tag description: > Patch-file: adeos-ipipe-2.6.15-arm-1.5-08.patch Yup, that one has me stumped - If you have any suggestions on eradicating the error, I'll use it. Should point out that the patch generation is *very* rough'n'ready in the absence of a kernel source tree. Regards, Paul. Index: debian/control === --- debian/control (revision 3185) +++ debian/control (working copy) @@ -14,9 +14,9 @@ Description: Linux kernel patches for Xe Xenomai kernel patches - See www.xenomai.org . Patches for 2.6 series kernels - These are intended for use with kernel-package - and a virgin linux source tree. Note: These patches include the base adeos-ipipe - patch along with all the additional material norma
Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6
On Wednesday 14 November 2007 16:37, Paul wrote:
> I'm right in the middle of looking at the packaging scripts, so expect a
> patch within the next few days.
Attached, one patch for the Debian rules. The debian/changelog version will
need to be bumped up to 2.4.0-1 once we get out of the -rc phase. I'll submit
a trivial patch at that point and build a set of i386 & amd64 packages.
Regards, Paul.
Index: debian/changelog
===
--- debian/changelog (revision 3182)
+++ debian/changelog (working copy)
@@ -1,3 +1,11 @@
+xenomai (2.4.0-0+rc6) unstable; urgency=low
+
+ * Update prepare-patch.sh to use combined x86/i386 Xenomai tree.
+ * Split patch generation out of build-stamp so that it only gets
+called once along with the configure.
+
+ -- Paul Corner <[EMAIL PROTECTED]> Wed, 14 Nov 2007 21:48:27 +
+
xenomai (2.3.50-05+r2299) unstable; urgency=low
* Add top level ChangeLog and CREDITS to each package.
Index: debian/prepare-patch.sh
===
--- debian/prepare-patch.sh (revision 3182)
+++ debian/prepare-patch.sh (working copy)
@@ -54,7 +54,6 @@ patch_link() {
if test ! -d $temp_tree/$link_dir/$d ; then
mkdir -p $temp_tree/$link_dir/$d
fi
-echo " cp $xenomai_root/$target_dir/$f $temp_tree/$link_dir/$f"
cp $xenomai_root/$target_dir/$f $temp_tree/$link_dir/$f
done
)
@@ -77,7 +76,6 @@ generate_patch() {
diff_addons() {
lines=`(echo ; echo ; cat $xenomai_root/scripts/Kconfig.frag) | wc -l`
-#echo "diff -u1wbr orig/arch/$linux_arch/Kconfig new/arch/$linux_arch/Kconfig" >> $patch_file
echo "--- linux/arch/$linux_arch/Kconfig 1970-01-01 01:00:00.0 +0100" >> $patch_file
echo "+++ linux-patched/arch/$linux_arch/Kconfig 2007-03-06 17:55:58.0 +" >> $patch_file
echo "@@ -40,2 +40,$lines @@" >> $patch_file
@@ -97,9 +95,22 @@ mkdir -p $xenomai_root/tmp/linux.new
linux_tree="$xenomai_root/tmp/linux"
temp_tree="$xenomai_root/tmp/linux.new"
+
for linux_arch in $supported_arch ; do
-patch_link r m ksrc/arch/$linux_arch arch/$linux_arch/xenomai
-patch_link r n include/asm-$linux_arch include/asm-$linux_arch/xenomai
+case $linux_arch in
+i386)
+base_arch=x86
+;;
+x86_64)
+base_arch=x86
+;;
+*)
+base_arch=$linux_arch
+;;
+esac
+
+patch_link r m ksrc/arch/$base_arch arch/$linux_arch/xenomai
+patch_link r n include/asm-$base_arch include/asm-$linux_arch/xenomai
p="+drivers-\$(CONFIG_XENOMAI) += arch/$linux_arch/xenomai/"
echo $p | patch_append arch/$linux_arch/Makefile
@@ -115,7 +126,6 @@ echo $p | patch_append kernel/Makefile
# Create local directories then symlink to the source files from
# there, so that we don't pollute the Xenomai source tree with
# compilation files.
-
patch_link n m ksrc/ kernel/xenomai
patch_link n m ksrc/arch kernel/xenomai/arch
patch_link r m ksrc/arch/generic kernel/xenomai/arch/generic
Index: debian/rules
===
--- debian/rules (revision 3182)
+++ debian/rules (working copy)
@@ -34,21 +34,25 @@ endif
--includedir=/usr/include/xenomai \
--mandir=/usr/share/man
-build: build-stamp
- ./configure $(CONFIG_OPTS)
+build: build-stamp patch-stamp
$(MAKE)
-# The kernel patches get generated next - Likely to involve some
-# additional scripting..
+
+patch-stamp:
+ dh_testdir
+ touch patch-stamp
+# The kernel patches get generated next - Need to revisit again
+# when 2.6.24 ipipe patch is released.
$(CURDIR)/debian/prepare-patch.sh arm i386 powerpc x86_64
build-stamp:
dh_testdir
touch build-stamp
+ ./configure $(CONFIG_OPTS)
clean:
dh_testdir
dh_testroot
- rm -f build-stamp
+ rm -f *-stamp
dh_clean
if test -f Makefile ; then \
$(MAKE) distclean 2>/dev/null ; \
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6
On Wednesday 14 November 2007 09:56, Leopold Palomo-Avellaneda wrote: > A Dimarts 13 Novembre 2007, Philippe Gerum va escriure: > > Here is the sixth candidate release for the v2.4.x branch. > > [] > > > [i386, x86_64 => x86] > > > > * Merge i386 and x86_64 arch-dep support as x86. > > * Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23. > > [...] > > this has break the creation of the debian packages. I can understand that > conceptually they are the same arch (one with 32bits and another with 64 > and more extensions) in general _all_ the distros treat them as two > different arch. So this changes break things. I don't think that it's a > good idea do it in a release candidate, IMHO. I'm right in the middle of looking at the packaging scripts, so expect a patch within the next few days. Giles/Philippe: Is there likely to be a 2.6.24 ipipe patch out before Xenomai reaches 2.4.0 ? Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Patch for configure --includedir
There is a small problem when --includedir is passed to configure which bites int the install-data-local rule in include/Makefile.am - The includedir variable is overridden by $(prefix)/include which causes a fatal error when attempting to generate symlinks. For example: ./configure --prefix=/tmp/foo --includedir=/usr/foo make install DESTDIR=/tmp/testit rm -f /tmp/testit/tmp/foo/include/asm ln -s asm-x86_64 /tmp/testit/tmp/foo/include/asm ln: creating symbolic link `/tmp/testit/tmp/foo/include/asm' to `asm-x86_64': No such file or directory make[3]: *** [install-data-local] Error 1 make[3]: Leaving directory `/tmp/xenomai/include' Regards, Paul. --- include/Makefile.am (revision 2902) +++ include/Makefile.am (working copy) @@ -1,4 +1,4 @@ -includedir = $(prefix)/include +#includedir = $(prefix)/include include_HEADERS = \ rtdk.h Index: sim/include/Makefile.am === --- sim/include/Makefile.am (revision 2902) +++ sim/include/Makefile.am (working copy) @@ -1,3 +1,3 @@ -includedir = $(prefix)/include/asm-sim +includesubdir = $(prefix)/include/asm-sim -nodist_include_HEADERS=$(CONFIG_HEADER) +nodist_includesub_HEADERS=$(CONFIG_HEADER) Index: sim/skins/posix/Makefile.am === --- sim/skins/posix/Makefile.am (revision 2902) +++ sim/skins/posix/Makefile.am (working copy) @@ -1,6 +1,6 @@ vpath %.c $(top_srcdir)/../ksrc/skins/posix -includedir = $(prefix)/include/asm-sim +includesubdir = $(prefix)/include/asm-sim CC = $(top_builddir)/gcic/gcic @@ -42,7 +42,7 @@ nodist_libposix_sim_a_SOURCES = \ shm.c \ module.c -include_HEADERS = \ +includesub_HEADERS = \ posix_overrides.h SUBDIRS = . testsuite demos ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Support EABI enabled kernels on ARM
Hi Gilles
On Monday 16 April 2007 23:36, Gilles Chanteperdrix wrote:
> And by the way, I am running Debian Etch, and its
> version of autotools seems to complain that we do not use datarootdir in
> xeno-config.in...
Attached, a trivial patch to fix the datarootdir warning.
Regards, Paul.
Index: scripts/xeno-config.in
===
--- scripts/xeno-config.in (revision 2393)
+++ scripts/xeno-config.in (working copy)
@@ -4,6 +4,7 @@ staging=${DESTDIR}
prefix="@prefix@"
exec_prefix="@exec_prefix@"
libdir="@libdir@"
+datarootdir="@datarootdir@"
datadir="@datadir@"
pkgdatadir="${datadir}/@PACKAGE@"
includedir="@includedir@"
@@ -20,7 +21,7 @@ XENO_POSIX_WRAPPERS="${staging}${libdir}
XENO_POSIX_FAST_WRAPPING="@LD_FILE_OPTION@"
XENO_LIBRARY_DIR="${staging}${libdir}"
-unset prefix exec_prefix libdir datadir pkgdatadir includedir
+unset prefix exec_prefix libdir datadir datarootdir pkgdatadir includedir
usage ()
{
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] missing native/ppd.h header
Hi Philippe Just tried to compile from r2361 in trunk, but `make dist` is failing due to include/native/ppd.h not present - Perusing the change logs, I see ppd.h was included in several native sources in r2361.. Should the reference be to nucleus/ppd.h or was the header missed out during a commit ? Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] More debian/rule diffs
Attached, a small patch to add a build dependency for findutils. Also includes
the top level CREDITS and ChangeLog in each package.
The configure options used to build the user space libraries now get included
in the package metadata which may be of interest to the user - Usefull if any
of the strong bindings are likely to cause problems.
Regards, Paul.
Index: debian/control
===
--- debian/control (revision 2299)
+++ debian/control (working copy)
@@ -2,7 +2,7 @@ Source: xenomai
Section: devel
Priority: extra
Maintainer: Paul Corner <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 5), build-essential, dh-kpatches
+Build-Depends: debhelper (>= 5), build-essential, dh-kpatches, findutils (>= 4.2.28)
Standards-Version: 3.7.2
Package: linux-patch-xenomai
Index: debian/changelog
===
--- debian/changelog (revision 2299)
+++ debian/changelog (working copy)
@@ -1,3 +1,10 @@
+xenomai (2.3.50-05+r2299) unstable; urgency=low
+
+ * Add top level ChangeLog and CREDITS to each package.
+ * rebuilt from SVN tag 2299
+
+ -- Paul Corner <[EMAIL PROTECTED]> Thu, 15 Mar 2007 11:03:14 +
+
xenomai (2.3.50-04) unstable; urgency=low
* Remove demo & snippets from the patches - Installed in xenomai-dev
Index: debian/rules
===
--- debian/rules (revision 2299)
+++ debian/rules (working copy)
@@ -30,11 +30,12 @@ endif
ifeq ($(DEB_BUILD_ARCH), arm)
CONFIG_OPTS =
endif
+ CONFIG_OPTS += --prefix=/usr \
+ --includedir=/usr/include/xenomai \
+ --mandir=/usr/share/man
build: build-stamp
- ./configure $(CONFIG_OPTS) --prefix=/usr \
- --includedir=/usr/include/xenomai \
- --mandir=/usr/share/man
+ ./configure $(CONFIG_OPTS)
$(MAKE)
# The kernel patches get generated next - Likely to involve some
# additional scripting..
@@ -68,8 +69,10 @@ install: build
mkdir -p $(CURDIR)/debian/xenomai-dev/usr/lib
mv -f $(CURDIR)/debian/tmp/usr/lib/*.a $(CURDIR)/debian/xenomai-dev/usr/lib
mv -f $(CURDIR)/debian/tmp/usr/include $(CURDIR)/debian/xenomai-dev/usr/
- mkdir -p $(CURDIR)/debian/xenomai-dev/usr/bin
+# Need posix.wrappers for xeno-config
+ mv -f $(CURDIR)/debian/tmp/usr/lib/posix.wrappers $(CURDIR)/debian/xenomai-dev/usr/lib
# The xeno-config only makes sense with headers & stuff.
+ mkdir -p $(CURDIR)/debian/xenomai-dev/usr/bin
mv -f $(CURDIR)/debian/tmp/usr/bin/xeno-config $(CURDIR)/debian/xenomai-dev/usr/bin
# Now for the documentation.
mkdir -p $(CURDIR)/debian/xenomai-docs/usr/share/
@@ -103,6 +106,13 @@ install: build
cd $(CURDIR)
# The kernel patches get installed next..
dh_installkpatches
+# Add CREDITS, ChangeLog, and READMEs to all packages.
+ for p in linux-patch-xenomai xenomai xenomai-dev xenomai-docs ; do \
+ mkdir -p $(CURDIR)/debian/$$p/usr/share/doc/$$p ; \
+ for f in CREDITS ChangeLog README.INSTALL TROUBLESHOOTING ; do \
+ install -m 0644 $$f $(CURDIR)/debian/$$p/usr/share/doc/$$p/ ; \
+ done ; \
+ done
# Build architecture-independent files here.
binary-indep: install
@@ -124,6 +134,12 @@ binary-indep: install
cat $(CURDIR)/debian/linux-patch-xenomai.kpatches | \
awk 'NR>4 {sub(/^/," ");print}' >> \
$(CURDIR)/debian/linux-patch-xenomai/DEBIAN/control
+# Echo config options to control.
+ echo " ." >> $(CURDIR)/debian/xenomai/DEBIAN/control
+ echo " Compiled with the following options." >> \
+ $(CURDIR)/debian/xenomai/DEBIAN/control
+ echo "$(CONFIG_OPTS)" | awk '{ for ( i=1 ; i<=NF ; i++ ) print " "$$i }' >> \
+ $(CURDIR)/debian/xenomai/DEBIAN/control
# End of hackery.
dh_md5sums
dh_builddeb
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] debian/rules update
On Wednesday 14 March 2007 11:14, Philippe Gerum wrote:
> On Wed, 2007-03-14 at 11:59 +0100, Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > On Tue, 2007-03-13 at 20:32 +, Paul wrote:
> > >>Hi Philippe
> > >>
> > >>On Tuesday 13 March 2007 16:30, Philippe Gerum wrote:
> > >>>>A question for the project admins: Do you have a Release Manager to
> > >>>>coordinate package releases ?
> > >>>
> > >>>I'm currently coordinating the Xenomai releases, with input from the
> > >>>sub-systems/architecture maintainers. I guess that by "package", you
> > >>> are referring to another division of the work, though.
> > >>
> > >>By "package", I mean binaries in the form of *.deb and/or *.rpm -
> > >> Whilst I'm happy to build and host i386/x86 Debian packages, I'm
> > >> concerned about treading on someone's toes without a discussion about
> > >> revision numbers and general policy about "official" releases.
> > >
> > > So far, we don't have an established policy for making distro-oriented
> > > packages; a few people have contributed some of them from time to time,
> > > but there is no "appointed" maintainer doing sustained work for the
> > > project on this issue yet.
> > >
> > >> For example, the packages I've
> > >>built to date have used 2.3.50 even although a tarball of that version
> > >> hasn't been released.. That could well cause confusion for users and
> > >> yourself if bugs are reported. There is also a minor problem with
> > >> keeping the debian/changelog in sync.
> > >>
> > >> One possible answer is for me to rebuild my repository from scratch
> > >> and append the SVN revision number to revision number so that we end
> > >> up with 2.3.50-1~r2289 - This would allow an official 2.3.50-1 release
> > >> to override the ~r2289 revision..
> > >
> > > It would be saner to use the commit number indeed, especially since it
> > > allows decouple the package versioning from the source releases while
> > > keeping a reference to a common history of changes.
> >
> > Do we really want to make debian packages with trunk ? Would not it make
> > sense to only make debian packages from stable releases ?
>
> Not necessarily, the same way one may want to base his work on sid,
> because some features only available in the development branch are
> needed (e.g. support for multiple time bases is only available in the
> trunk/ and not with 2.3.x, and one would need such feature to run
> VxWorks and the POSIX skins in parallel for instance). Provided we do
> have a non-confusing way to name such intermediate releases, of course.
With a Debian pool style of repository, the X.Y.50+rnnn packages would always
go in unstable (Sid) or even experimental. When the release number gets
bumped up to X.{Y+1}.0, it would go in testing (Etch), and when Etch becomes
the default "stable", any X.Y.0 releases would automatically migrate across.
Bug fixes to X.Y.{0+n} would normally appear in testing and/or stable leaving
Sid to track the trunk of SVN - Primarily a repository management issue..
Following this proposal, the end user can opt for stable/testing or unstable.
Should he/she choose, it is a simple matter to "downgrade" from unstable or
track the unstable releases.. That said, I suspect most users would compile
from source, perhaps using the debian/rules as an aid to install/remove..
Prebuilt binaries & kernels would most likely be used by people wanting to
try Xenomai before committing time to a patch/build cycle.
Regards, Paul.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] debian/rules update
On Wednesday 14 March 2007 10:56, Philippe Gerum wrote:
> On Tue, 2007-03-13 at 20:32 +0000, Paul wrote:
> > Hi Philippe
> >
> > On Tuesday 13 March 2007 16:30, Philippe Gerum wrote:
> > > > A question for the project admins: Do you have a Release Manager to
> > > > coordinate package releases ?
> > >
> > > I'm currently coordinating the Xenomai releases, with input from the
> > > sub-systems/architecture maintainers. I guess that by "package", you
> > > are referring to another division of the work, though.
> >
> > By "package", I mean binaries in the form of *.deb and/or *.rpm - Whilst
> > I'm happy to build and host i386/x86 Debian packages, I'm concerned about
> > treading on someone's toes without a discussion about revision numbers
> > and general policy about "official" releases.
>
> So far, we don't have an established policy for making distro-oriented
> packages; a few people have contributed some of them from time to time,
> but there is no "appointed" maintainer doing sustained work for the
> project on this issue yet.
>
> > For example, the packages I've
> > built to date have used 2.3.50 even although a tarball of that version
> > hasn't been released.. That could well cause confusion for users and
> > yourself if bugs are reported. There is also a minor problem with keeping
> > the debian/changelog in sync.
> >
> > One possible answer is for me to rebuild my repository from scratch and
> > append the SVN revision number to revision number so that we end up with
> > 2.3.50-1~r2289 - This would allow an official 2.3.50-1 release to
> > override the ~r2289 revision..
>
> It would be saner to use the commit number indeed, especially since it
> allows decouple the package versioning from the source releases while
> keeping a reference to a common history of changes.
>
> Some information about the current naming scheme I'm using for tagging
> the intermediate development milestones:
>
> 1- when reopened after a major version X.Y has been rolled out, the
> development branch (i.e. SVN trunk/) is always tagged as X.Y.50. There
> is no X.Y.51 version and beyond; the next step is always to enter the
> release candidate cycle when appropriate.
That sounds reasonable - Any packages built from trunk would probably better
off following an X.Y.50+r.
> 2- when the development branch enters the release candidate cycle, this
> tag is bumped to X.Y.90 for -rc1, X.Y.91 for -rc2 and so on.
>
> 3- a release candidate that goes final is eventually tagged as X.{Y
> +1}.O, and the development cycle restarts at step 1.
So X.{Y+1}.0 will always override an X.Y.50+r - Works for me.
Regards, Paul.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] debian/rules update
Hi Philippe On Tuesday 13 March 2007 16:30, Philippe Gerum wrote: > > A question for the project admins: Do you have a Release Manager to > > coordinate package releases ? > > I'm currently coordinating the Xenomai releases, with input from the > sub-systems/architecture maintainers. I guess that by "package", you are > referring to another division of the work, though. By "package", I mean binaries in the form of *.deb and/or *.rpm - Whilst I'm happy to build and host i386/x86 Debian packages, I'm concerned about treading on someone's toes without a discussion about revision numbers and general policy about "official" releases. For example, the packages I've built to date have used 2.3.50 even although a tarball of that version hasn't been released.. That could well cause confusion for users and yourself if bugs are reported. There is also a minor problem with keeping the debian/changelog in sync. One possible answer is for me to rebuild my repository from scratch and append the SVN revision number to revision number so that we end up with 2.3.50-1~r2289 - This would allow an official 2.3.50-1 release to override the ~r2289 revision.. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] debian/rules update
Attached, a patch to include code examples in the final -dev package along
with some cleanup of the patches. Also contains a bug fix for the postinst
script that I hit on when installing a new build.
A question for the project admins: Do you have a Release Manager to coordinate
package releases ?
Regards, Paul.
Index: debian/control
===
--- debian/control (revision 2291)
+++ debian/control (working copy)
@@ -14,7 +14,12 @@ Description: Linux kernel patches for Xe
Xenomai kernel patches - See www.xenomai.org
.
Patches for 2.6 series kernels - These are intended for use with kernel-package
- and a virgin linux source tree.
+ and a virgin linux source tree. Note: These patches include the base adeos-ipipe
+ patch along with all the additional material normally added by the prepare-kernel.sh
+ script.
+ .
+ This package contains the following patches:
+ .
Package: xenomai
Section: devel
@@ -37,6 +42,9 @@ Description: Headers and static libs for
.
This package also contains the static libraries and scripts used
to compile realtime applications.
+ .
+ User space and kernel examples can be found in /usr/share/xenomai
+ along with suitable make files.
Package: xenomai-docs
Section: devel
Index: debian/xenomai.postinst
===
--- debian/xenomai.postinst (revision 2291)
+++ debian/xenomai.postinst (working copy)
@@ -1,5 +1,6 @@
#!/bin/sh
-ln -s ../xenomai.rules /etc/udev/rules.d/xenomai.rules
+rm -f /etc/udev/rules.d/xenomai.rules
+ln -sf ../xenomai.rules /etc/udev/rules.d/xenomai.rules
#DEBHELPER#
Index: debian/prepare-patch.sh
===
--- debian/prepare-patch.sh (revision 2291)
+++ debian/prepare-patch.sh (working copy)
@@ -64,8 +64,9 @@ echo " cp $xenomai_root/$target_dir/$f $
generate_patch() {
(
cd "$temp_tree"
+find . -name demos -o -name snippets -exec rm -fR {} \+ &&
find . -type f |
-while read f; do
+while read f ; do
diff -Naurd "$linux_tree/$f" "$f" |
sed -e "s,^--- ${linux_tree}/\.\(/.*\)$,--- linux\1," \
-e "s,^+++ \.\(/.*\)$,+++ linux-patched\1,"
@@ -139,8 +140,6 @@ echo "Patch-name: Xenomai realtime kerne
echo "Patch-id: xenomai" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
echo "Architecture: all" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
-echo "" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
-
find $xenomai_root/ksrc/ -name "adeos-ipipe-2.6.*.patch" |
while read f ; do
Index: debian/changelog
===
--- debian/changelog (revision 2291)
+++ debian/changelog (working copy)
@@ -1,3 +1,18 @@
+xenomai (2.3.50-04) unstable; urgency=low
+
+ * Remove demo & snippets from the patches - Installed in xenomai-dev
+ * linux-patches-xenomai lists patches, architectures, & kernel version
+in the package description meta-data.
+
+ -- Paul Corner <[EMAIL PROTECTED]> Mon, 12 Mar 2007 17:30:00 +0000
+
+xenomai (2.3.50-03) unstable; urgency=low
+
+ * Revision 2281
+ * Fix bug in postinst script - Need to overwrite the symlink
+
+ -- Paul Corner <[EMAIL PROTECTED]> Sun, 11 Mar 2007 20:30:00 +
+
xenomai (2.3.50-02) unstable; urgency=low
* Apply patch to fix includedir bug - rules updated..
Index: debian/rules
===
--- debian/rules (revision 2291)
+++ debian/rules (working copy)
@@ -86,17 +86,26 @@ install: build
# test applications.
mkdir -p $(CURDIR)/debian/xenomai/usr/share
mv -f $(CURDIR)/debian/tmp/usr/share/xenomai $(CURDIR)/debian/xenomai/usr/share
- mkdir -p $(CURDIR)/debian/xenomai/etc/udev
# install $(CURDIR)/ksrc/nucleus/udev/*.rules $(CURDIR)/debian/xenomai/etc/udev
+ mkdir -p $(CURDIR)/debian/xenomai/etc/udev
for f in $(CURDIR)/ksrc/nucleus/udev/*.rules ; do \
cat $$f >> $(CURDIR)/debian/xenomai/etc/udev/xenomai.rules ; \
done
+# Install examples in the dev package.
+ mkdir -p $(CURDIR)/debian/xenomai-dev/usr/share/xenomai
+ cp -fR $(CURDIR)/examples $(CURDIR)/debian/xenomai-dev/usr/share/xenomai
+# then kernel demos & snippets
+ cd $(CURDIR)/ksrc && find . -name demos -o -name snippets | \
+ while read d ; do \
+ mkdir -p $(CURDIR)/debian/xenomai-dev/usr/share/xenomai/examples/kernel/$$d ; \
+ install -m 0644 $$d/* $(CURDIR)/debian/xenomai-dev/usr/share/xenomai/examples/kernel/$$d ; \
+ done ; \
+ cd $(CURDIR)
# The kernel patches get installed next..
dh_installkpatches
-
# Build architecture-independent files here.
-binary-indep: build install
+binary-indep: install
dh_testdir
dh_testroot
dh_installdocs
@@ -110,6 +119,12 @@ binary-indep: bu
Re: [Xenomai-core] Debian rule set.
On Monday 12 March 2007 14:03, Philippe Gerum wrote: >> Is it possible to change the svn properties on these two files ? > > Yes. Should be ok now. Thanks - That will stop dpkg barfing when trying to build a package. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian rule set.
Hi Philippe On Monday 12 March 2007 13:15, Philippe Gerum wrote: > > Attached is a second draft of the rule set > Merged, thanks. Updated my local copy and noticed the execute attributes are not set for debian/rules or debian/prepare-patch.sh - Is it possible to change the svn properties on these two files ? Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] Xenomai & kernel packages for Debian
Hi Jan On Sunday 11 March 2007 20:57, Jan Kiszka wrote: > Nice work! Hope that some people give this a try -- and report their > findings here. Judging by the web logs, several people have downloaded some of the packages.. Just to keep 'em on their toes, another set of x86_64 builds were added last night ;) > Maybe you should create a dedicated page in the wiki to help those who > do not immediately know what to do with the repos, explain what is > contained, and tell beginners how to get it running quickly. Most people interested in the packages wouldn't be *nix beginners and would probably have some knowledge of the apt tools. That said, there are some gotchas that would be worth documenting along with some commentary on make-kpkg & patching. On the todo list is an improvement of package descriptions, embedding supported kernel/arch data in linux-patches-xenomai. Perhaps adding an m4 & makefile.am snippet to the dev package.. Maybe copying assorted examples from the root directory and in ksrc/skins to xenomai-dev. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai & kernel packages for Debian
Having patched and built some kernel packages for Debian (for internal use), I've uploaded them to a server so that others can try them out. Currently a have set of 2.6.19.5 kernels and supporting Xenomai packages available for x86_64 and i386 (compiled for 686). The repository is located at http://zathras.tuxcnc.org/xenomai - Although the packages are all in Sid, they have been compiled on Etch boxen, so should work with both Debian's testing/unstable and Ubuntu. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] --includedir ignored
On Wednesday 07 March 2007 23:15, Philippe Gerum wrote: > include/compat is not installed on purpose, since what goes to > $(prefix)/include is aimed at compiling user-space code only, and files > under the compat/ root are placeholders for compiling Xenomai-enabled > 2.4 kernels. OK - That makes sense.. If the compat/ includes are specific to 2.4 kernels, then there would be little reason to put them in any 2.6 patches. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian rule set.
On Wednesday 07 March 2007 22:57, Gilles Chanteperdrix wrote: > > be a minor issue with the --includedir option. > > The attached patch should solve this issue. That works for me.. Attached is a second draft of the rule set - Took the liberty of adding the files to the EXTRA_DIST rule as well as packaging the includes under /usr/include/xenomai. Regards, Paul. debian_rules.2.patch.bz2 Description: BZip2 compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian rule set.
Hi Gilles On Wednesday 07 March 2007 19:51, Gilles Chanteperdrix wrote: > That is great. It means that we should try and solve the includedir > issue. However, from a maintenance point of view, would not it make mor > sense to modify the prepare-kernel script to that it suits the needs of > debian packaging than to have a second script almost like it in the > debian directory ? Modifying the prepare-kernel script would be preferable in the long term, but I didn't see much point initially for three reasons - The initial rule set is "proof of concept" and would benefit from some peer review (also need to tweak a few lines).. Second, the prepare-kernel script would require extensive modifications for the needs of one or two people. Finally, the kernel patching system in Debian has some new features currently in "experimental", so when these make their way in to testing/unstable, the prepare-kernel & patch generation would need to be overhauled. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Debian rule set.
Attached is a rule set for generating a series of Debian packages. Four packages are generated, these are: linux-patch-xenomai - A collection of adeos-ipipe patches with the Xenomai kernel parts tacked on. The script used to combine the parts is a hacked down version of prepare-kernel.sh.. xenomai-dev - Headers, static libs, and xeno-config. I would have liked to move the headers in to a /usr/include/xenomai directory, but there appears to be a minor issue with the --includedir option. xenomai-docs - All the API documentation in man, html, and pdf format as found in the repository (don't see much point in regenerating and adding to build dependencies). xenomai - The core libraries, run scripts, and assorted tests/utilities. The configure options could probably do with some adjustments, but I've kept arch dependant options segregated so conflicts can be kept to a minimum. A couple of general comments: Having a clear seperation of kernel & user space sources has greatly simplified the task of packaging.. The dynamic libs all have a 0.0.0 version - Would it not make sense to sync with the Xenomai version ? Regards, Paul. debian_rules.patch.bz2 Description: BZip2 compressed data ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] --includedir ignored
Exploring some of the configure options with the view to generating a Debian rule and I noticed a bug (?) in the make files - Passing an --includedir option to configure, during the install phase, the given directory path is ignored and make eventually bombs out when trying to create an asm/ symlink. Checking the include/ Makefile.am and it's siblings, I note includedir is overridden by $(prefix)/include/ and $(prefix)/include/asm-, yet include/Makefile.am honours the $(includedir) config variable when attempting to create the symlink. Also noted that include/compat/ headers don't get installed - Is this, and the $(includedir) issue an oversight ? Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] prepare-kernel options
On Wednesday 28 February 2007 13:02, Jan Kiszka wrote: > [Related question from my side:] > > Would you be willing to provide debian package generation rules for > Xenomai? Something that would spit out .deb files when calling, say, > "make deb KERNEL=linux-2.6.x.tar.bz2 CONFIG=my-kernel-config" in a > configured userland build directory? That way we could automatise binary > package generation for kernel, user libs, development headers, and > documentation. And that would allow us to finally distribute them for > generic targets like x86 and x86_64 along with the usual tar files. To have a Debian rule set is indeed my ultimate goal (but I wouldn't want t tread on anyone's toes if it is already in hand). - I suspect a number of potential users would like to try Xenomai but are put off by kernel compilation... But rather than a `make deb` rule, a small script would be better - Debian's packaging system generates (amongst other things) a source tarball, and to include auto-generated files doesn't feel right.. Calling the `make dist` rule may solve that issue. > I think such a feature (maybe later enhanceable by RPM) would both be > interesting for replicable custom installations as well as for a > reference kernel distribution to provide a Xenomai quick-start. Indeed - Point a potential user to a repository, let them experiment with a (hopefully) working kernel, and when they need/want specific vmlinuz options, they have a reference point to work from. The "Debian way" also greatly simplifies the task of building packages. > Would this build procedure already help you? > http://www.rts.uni-hannover.de/xenomai/lxr/source/README.INSTALL?a=i386#203 Ah, yes.. It's the same doc in the top level Xenomai tree ;) As Gilles has pointed out, there are already a couple of options in prepare-kernel.sh to aid package generation - If nobody else is working on that area, I'll put a patch together over the next few days and submit it for review. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] prepare-kernel options
A little background - On Debian installations, a set of tools have been
provided to allow kernel packages to be quickly & simply generated. It is
something I do quite regularly with the following steps:
* Extract kernel sources in /tmp
* Apply patches
* Copy an existing .config over - Run `make oldconfig`
* make-kpkg binary-arch (produces kernel-image and kernel-header packages)
* Install/reboot
It may sound a long winded method, but it does allow me to use the generated
packages to install on any number of other machines.
The problem - prepare-kernel.sh creates symlinks to assorted files in the
Xenomai source tree. Not a problem if the same tree exists in the same
location on the target machine. As yet, there is no xenomai Debian package,
and the build location may not be the same as the install location - This
results in a large number of dangling symlinks which thwarts attempts to
compile out of tree modules using the kernel-headers package. I suspect the
same issues would exist for RPM packages and NFS mounted targets.
A solution - Instead of creating symlinks, the files need to be copied in to
the kernel source tree. Most people will use symlinks as it simplifies the
`svn up`/make process and avoids having to run prepare-kernel each time. I
propose a trivial patch that retains the original behaviour and provides an
option to turn off symlinks (patch attached).
Regards, Paul.
Index: scripts/prepare-kernel.sh
===
--- scripts/prepare-kernel.sh (revision 2265)
+++ scripts/prepare-kernel.sh (working copy)
@@ -95,6 +95,11 @@ patch_link() {
if test x$link_makefiles = xm; then
link_makefiles_opt="-name Makefile -o"
fi
+if test x$no_symlinks = x1; then
+link_command="cp -f"
+else
+link_command="cp -sf"
+fi
if test "x$output_patch" = "x" -a -e $linux_tree/$link_dir; then
cd $linux_tree/$link_dir &&
@@ -116,7 +121,7 @@ patch_link() {
if test x$forcelink = x1 -o \
! $xenomai_root/$target_dir/$f -ef $linux_tree/$link_dir/$f;
then
-ln -sf $xenomai_root/$target_dir/$f $linux_tree/$link_dir/$f
+$link_command $xenomai_root/$target_dir/$f $linux_tree/$link_dir/$f
fi
else
if test `check_filter $link_dir/$f` = "ok"; then
@@ -168,7 +173,7 @@ generate_patch() {
}
-usage='usage: prepare-kernel --linux= --adeos= [--arch=] [--outpatch= [--filterkvers=y|n] [--filterarch=y|n]] [--forcelink]'
+usage='usage: prepare-kernel --linux= --adeos= [--arch=] [--outpatch= [--filterkvers=y|n] [--filterarch=y|n]] [--forcelink] [--nosymlink]'
me=`basename $0`
while test $# -gt 0; do
@@ -198,6 +203,9 @@ while test $# -gt 0; do
--forcelink)
forcelink=1
;;
+--nosymlink)
+no_symlinks=1
+;;
--verbose)
verbose=1
;;
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] x86_64 - missing header
Hi Philippe
Trying very hard to keep up with the rate of commits - The latest 1.0-05 patch
in conjuntion with r2264 fails with the error:
arch/x86_64/xenomai/hal.c:51:22: error: mach_ipi.h: No such file or directory
arch/x86_64/xenomai/hal.c: In function ‘rthal_broadcast_to_local_timers’:
arch/x86_64/xenomai/hal.c:104: warning: implicit declaration of
function ‘send_IPI_all’
Looks like mach_ipi.h is missing from my 2.6.19 tree, but the function is
declared in asm/mach_apic.h - The attached patch resolves this minor problem.
Regards, Paul.
Index: ksrc/arch/x86_64/hal.c
===
--- ksrc/arch/x86_64/hal.c (revision 2264)
+++ ksrc/arch/x86_64/hal.c (working copy)
@@ -48,7 +48,7 @@
#include
#include
#include
-#include
+#include
#include
static struct {
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] x86_64 - Initial results.
Hi Philippe
On Sunday 25 February 2007 22:00, Philippe Gerum wrote:
> > Results are still the same - Latency goes to pot and hangs as soon as X
> > starts up. Quite likely the offending trace isn't getting logged..
>
> Just for the purpose of digging the issue further, does this particular
> problem persist when MTRRs are switched off from the kernel config?
I'd just finished compiling yet another kernel with CONFIG_MTRR disabled and
was about to run another test..
Logs attached - Even with ipipe-trace enabled, latencies are acceptable when
firing up X/KDE..
Regards, Paul.
I-pipe frozen back-tracing service on 2.6.19.3-xenomai/ipipe-1.0-04
Freeze: 970774923862 cycles, Trace Points: 30 (+100)
Calibrated minimum trace-point overhead: 0.037 us
+- Hard IRQs ('|': locked)
|+
||+---
|||+-- Xenomai
+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
|+-- Delay flag ('+': > 1 us, '!': > 10 us)
||+- NMI noise ('N')
|||
TypeUser Val. TimeDelay Function (Parent)
:| # func -30.067 xnpod_schedule+0x16
(xnintr_irq_handler+0x116)
:| # [ 3008] Xorg-1-30.231 xnpod_schedule+0xa8
(xnintr_irq_handler+0x116)
:| # func -20.343 __switch_to+0x16 (xnpod_schedule+0x80b)
:| # [ 2716] samplin 99-20.134 xnpod_schedule+0x848
(xnpod_suspend_thread+0x154)
:| # func -20.065 __ipipe_restore_pipeline_head+0x16
(xnpod_wait_thread_period+0x11e)
:| + end 0x8000-20.163 __ipipe_restore_pipeline_head+0xb1
(xnpod_wait_thread_period+0x11e)
:| + begin 0x8001-20.073 __ipipe_dispatch_event+0xe9
(__ipipe_syscall_root+0x8d)
:| + end 0x8001-20.088 __ipipe_dispatch_event+0x191
(__ipipe_syscall_root+0x8d)
:| + begin 0x8000-20.326 __ipipe_syscall_root+0x14b
(__ipipe_syscall_root_thunk+0x35)
: + func -10.076 __ipipe_syscall_root+0xc
(__ipipe_syscall_root_thunk+0x35)
: + func -10.071 __ipipe_dispatch_event+0x16
(__ipipe_syscall_root+0x8d)
:| + begin 0x8001-10.048 __ipipe_dispatch_event+0x37
(__ipipe_syscall_root+0x8d)
:| + end 0x8001-10.070 __ipipe_dispatch_event+0xb6
(__ipipe_syscall_root+0x8d)
: + func -10.098 hisyscall_event+0x21
(__ipipe_dispatch_event+0xc7)
: + func -10.077 __rt_timer_tsc2ns+0xe [xeno_native]
(hisyscall_event+0x1bb)
: + func -10.144 rt_timer_tsc2ns+0x9 [xeno_native]
(__rt_timer_tsc2ns+0x2c [xeno_native])
:| + begin 0x8001-10.072 __ipipe_dispatch_event+0xe9
(__ipipe_syscall_root+0x8d)
:| + end 0x8001-10.078 __ipipe_dispatch_event+0x191
(__ipipe_syscall_root+0x8d)
:| + begin 0x8000 00.139 __ipipe_syscall_root+0x14b
(__ipipe_syscall_root_thunk+0x35)
: + func 00.063 __ipipe_syscall_root+0xc
(__ipipe_syscall_root_thunk+0x35)
: + func 00.064 __ipipe_dispatch_event+0x16
(__ipipe_syscall_root+0x8d)
:| + begin 0x8001 00.056 __ipipe_dispatch_event+0x37
(__ipipe_syscall_root+0x8d)
:| + end 0x8001 00.061 __ipipe_dispatch_event+0xb6
(__ipipe_syscall_root+0x8d)
: + func 00.151 hisyscall_event+0x21
(__ipipe_dispatch_event+0xc7)
: + func 00.059 xnshadow_sys_trace+0x16
(hisyscall_event+0x1bb)
: + func 00.127 ipipe_trace_frozen_reset+0xa
(xnshadow_sys_trace+0x8a)
: + func 00.051 __ipipe_global_path_lock+0xa
(ipipe_trace_frozen_reset+0x14)
:| + begin 0x8001 00.120 __ipipe_global_path_lock+0x1c
(ipipe_trace_frozen_reset+0x14)
:| + end 0x8001 00.066 __ipipe_global_path_unlock+0x62
(ipipe_trace_frozen_reset+0x61)
< + freeze 0x543e 00.084 xnshadow_sys_trace+0x94
(hisyscall_event+0x1bb)
| + begin 0x8001 00.062 __ipipe_dispatch_event+0xe9
(__ipipe_syscall_root+0x8d)
| + end 0x8001 00.083 __ipipe_dispatch_event+0x191
(__ipipe_syscall_root+0x8d)
| + begin 0x8000 00.131 __ipipe_syscall_root+0x14b
(__ipipe_syscall_root_thunk+0x35)
+ func 00.066 __ipipe_syscall_root+0xc
(__ipipe_syscall_root_thunk+0x35)
+ func 00.064 __ipipe_dispatch_event+0x16
(__ipipe_syscall_root+0x8d)
| + begin 0x8001 00.057 __ipipe_dispatch_event+0x37
(__ipipe_syscall_root+0x8d)
| + end 0x8001 00.071 __ipipe_dispatch_event+0xb6
(__ipipe_syscall_root+0x8d)
+ func
Re: [Xenomai-core] x86_64 - Initial results.
On Sunday 25 February 2007 16:03, Jan Kiszka wrote: > > The attached trace logs provide little information - Also included dmesg > > One more try please: we also need CONFIG_IPIPE_TRACE_MCOUNT. With both CONFIG_IPIPE_TRACE_MCOUNT and CONFIG_IPIPE_TRACE_VMALLOC enabled, the system auto-reboots as soon as the kernel starts to uncompress. Disabling the latter restores normal service. On Sunday 25 February 2007 16:09, Gilles Chanteperdrix wrote: > Option "NoAccel" Results are still the same - Latency goes to pot and hangs as soon as X starts up. Quite likely the offending trace isn't getting logged.. Regards, Paul. [0.00] Linux version 2.6.19.3-xenomai ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #7 Sun Feb 25 17:58:53 GMT 2007 [0.00] Command line: root=/dev/sda2 ro splash=silent vga=788 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1ffb (usable) [0.00] BIOS-e820: 1ffb - 1ffc (ACPI data) [0.00] BIOS-e820: 1ffc - 1fff (ACPI NVS) [0.00] BIOS-e820: 1fff - 2000 (reserved) [0.00] BIOS-e820: ff78 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 130992) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP (v000 ACPIAM) @ 0x000fa810 [0.00] ACPI: RSDT (v001 A M I OEMRSDT 0x01000723 MSFT 0x0097) @ 0x1ffb [0.00] ACPI: FADT (v001 A M I OEMFACP 0x01000723 MSFT 0x0097) @ 0x1ffb0200 [0.00] ACPI: MADT (v001 A M I OEMAPIC 0x01000723 MSFT 0x0097) @ 0x1ffb0390 [0.00] ACPI: OEMB (v001 A M I OEMBIOS 0x01000723 MSFT 0x0097) @ 0x1ffc0040 [0.00] ACPI: DSDT (v001 A0277 A0277001 0x0001 MSFT 0x010d) @ 0x [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 130992) 1 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 130992 [0.00] On node 0 totalpages: 130895 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1700 pages reserved [0.00] DMA zone: 2243 pages, LIFO batch:0 [0.00] DMA32 zone: 1734 pages used for memmap [0.00] DMA32 zone: 125162 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x808 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] WARNING: NR_CPUS limit of 1 reached. Processor ignored. [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Setting APIC routing to flat [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Nosave address range: 0009f000 - 000a [0.00] Nosave address range: 000a - 000e4000 [0.00] Nosave address range: 000e4000 - 0010 [0.00] Allocating PCI resources starting at 3000 (gap: 2000:df78) [0.00] Built 1 zonelists. Total pages: 127405 [0.00] Kernel command line: root=/dev/sda2 ro splash=silent vga=788 [0.00] Initializing CPU#0 [0.00] PID hash table entries: 2048 (order: 11, 16384 bytes) [ 28.777403] time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. [ 28.777410] time.c: Detected 2403.177 MHz processor. [ 28.777485] I-pipe 1.0-04: pipeline enabled. [ 28.777553] Console: colour dummy device 80x25 [ 28.778250] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) [ 28.778657] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) [ 28.778737] Checking aperture... [ 28.778745] CPU 0: aperture @ f000 size
Re: [Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started
On Sunday 25 February 2007 00:15, Paul wrote: > Hi Philippe > > On Saturday 24 February 2007 22:46, Philippe Gerum wrote: > > Added to the fact that I've just fixed the CONFIG_SMP > > +CONFIG_PREEMPT issue [1], what remains to get a fully functional > > preliminary x86_64 port is to solve the CONFIG_SMP+CONFIG_IPIPE_TRACE, > > and we should be done. > > If CONFIG_PREEMPT is not enabled, the kernel compile fails with: > > arch/x86_64/kernel/built-in.o: In function `__ipipe_preempt_schedule_irq': > arch/x86_64/kernel/ipipe.c:471: undefined reference to > `preempt_schedule_irq' make[1]: *** [.tmp_vmlinux1] Error 1 > make[1]: Leaving directory `/var/tmp/linux-2.6.19.3' > make: *** [debian/stamp-build-kernel] Error 2 > > The attached patch addresses the problem.. Scrub that - It exposes another problem in thunk.S which I missed... Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started
Hi Philippe
On Saturday 24 February 2007 22:46, Philippe Gerum wrote:
> Added to the fact that I've just fixed the CONFIG_SMP
> +CONFIG_PREEMPT issue [1], what remains to get a fully functional
> preliminary x86_64 port is to solve the CONFIG_SMP+CONFIG_IPIPE_TRACE,
> and we should be done.
If CONFIG_PREEMPT is not enabled, the kernel compile fails with:
arch/x86_64/kernel/built-in.o: In function `__ipipe_preempt_schedule_irq':
arch/x86_64/kernel/ipipe.c:471: undefined reference to `preempt_schedule_irq'
make[1]: *** [.tmp_vmlinux1] Error 1
make[1]: Leaving directory `/var/tmp/linux-2.6.19.3'
make: *** [debian/stamp-build-kernel] Error 2
The attached patch addresses the problem..
Regards, Paul.
diff -uwpr linux-2.6.19.3-orig/arch/x86_64/kernel/ipipe.c linux-2.6.19.3/arch/x86_64/kernel/ipipe.c
--- linux-2.6.19.3-orig/arch/x86_64/kernel/ipipe.c 2007-02-24 23:36:04.0 +
+++ linux-2.6.19.3/arch/x86_64/kernel/ipipe.c 2007-02-24 23:58:07.0 +
@@ -44,7 +44,9 @@
#include
#include
+#ifdef CONFIG_PREEMPT
asmlinkage void preempt_schedule_irq(void);
+#endif
struct pt_regs __ipipe_tick_regs[IPIPE_NR_CPUS];
@@ -450,6 +452,7 @@ static inline void __fixup_if(struct pt_
ipipe_put_cpu(flags);
}
+#ifdef CONFIG_PREEMPT
/* Check the stall bit of the root domain to make sure the existing
preemption opportunity upon in-kernel resumption could be
exploited. In case a rescheduling could take place, the root stage
@@ -475,6 +478,7 @@ asmlinkage int __ipipe_preempt_schedule_
return 1;
}
+#endif /* CONFIG_PREEMPT */
asmlinkage int __ipipe_syscall_root(struct pt_regs *regs)
{
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] x86_64 - Initial results.
Hi Philippe First off, thanks for all your hard work and late nights (and the rest of the team) for the x86_64. Initial results look promising with the latency test reporting figures in the 0.5 to 4 uSec range under light load. A kernel compile bumps the wost up to 9-14uSec. Firing up X,KDE, and a gamut of desktop apps really kills the numbers though - ~267uSec being the worst recorded so far, however, once X/KDE has started up, latencies are generally <30uSec. One small problem to report from the compile... With CONFIG_XENO_OPT_NUCLEUS=m, the build fails with: WARNING: "cpu_gdt_descr" [kernel/xenomai/nucleus/xeno_nucleus.ko] undefined! make[1]: *** [__modpost] Error 1 What would the preferred solution be - Export cpu_gdt_descr as it is with i386, or force xeno_nucleus to be built in ? Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Adeos-main] Re: Heads up: Xenomai port over x86_64 has started
Hi Gilles On Friday 23 February 2007 20:01, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > On Wed, 2007-01-31 at 01:58 +0100, Philippe Gerum wrote: > > > Ok, no more distant rumblings about x86_64: a Xenomai port to this > > > architecture has officially started. A preliminary version of the > > > I-pipe for x86_64 is now available, which I'm going to use to port the > > > Xenomai core. > > > > Here we are. The following revised I-pipe patch is stable enough to run > > the Xenomai trunk/ on a 4-way Opteron, and on qemu-x86_64 0.8.2 too: > > http://download.gna.org/adeos/patches/v2.6/x86_64/adeos-ipipe-2.6.19-x86 > >_64-1.0-02.patch > > > > The status of the Xenomai/x86_64 port is as follows: > > > > - real-time support in user-space is mostly ok, except the FPU > > management over the Xenomai domain which is broken beyond all > > recognition. Gilles, as already discussed, I won't resist to let you > > bang your head on this wall instead of mine, because 1) this will allow > > me to switch to the pending issues people have raised on the lists so > > far, 2) I'm fundamentally evil, 3) the fact that you once did dare > > rewriting the FPU support for Xenomai/x86 clearly shows that you do have > > some masochistic tendencies anyway. > > Ok, I will do it. Do you have an URL of a datasheet at hand (since the > x86 code does not work, there must be some difference) ? http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html has links for assorted low level docs - Vol.5 should cover the area in question. > By the way, there is a change that I made to the i386 context switching > routine which I think you should make to the x86_64 one: mark all > register as output registers, this prevent the compiler from considering > that the value of a particular register survived the context > switch. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] [RFT] RTnet on x86_64
Hi Jan On Friday 23 February 2007 23:30, Jan Kiszka wrote: > recent development on Xenomai and the underlying I-pipe patch [1] > reached a point where real experiments on yet another architecture for > RTnet are starting to make sense. > > In fact, RTnet has been enabled to build over x86_64 already two weeks > back, including a necessary fix to the RTDM layer. I just checked again: > it still compiles fine. 8) > > I'm lacking a test platform, so _you_ have the unique chance to be the > first person running RTnet on 64 bits! Grab a 2.6.19 kernel and the > latest I-pipe patch [2], checkout Xenomai [3] and RTnet trunk [4]. Put > everything on some native 64-bit Linux installation and give it hell. As you probably know, I've already committed to running tests over the weekend on real hardware - Not being familiar with RTnet, are there any test suites that can be used on say i386<->AMD64<->ppc ? > Ah, and don't forget to report your findings! /me is good at breaking "stuff" and reporting the results ;) Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rtdm over x86_64
On Saturday 03 February 2007 15:08, Jan Kiszka wrote: > Yeah, when looking at this issue with 64-bit glasses, this urgently > needs fixing (I wonder why ia64 didn't stumble yet?). Perhaps different compiler and/or warning flags ? Using gcc-4.1 at the moment.. > init/Kconfig:572: can't open file "arch/x86_64/xenomai/Kconfig" > > Anyone any idea? Is something missing, or is the prepare script broken? I must admit, saw the first of the commits announced on http://cia.navi.cx/stats/project/xenomai and butchered a tree to see what else was needed.. I'll wait for Philippe to finish his commits before preempting him again. > PS: Once we have in-tree RTDM services and drivers running, are you > interested in a RTnet excursion over x64? I should be able to make this > compile, but for testing... RTnet across a local net and/or a machine in your lab via the internet - Could be fun :) If you have some ready to run code, I can set aside an afternoon to run some tests - Perhaps even set up an ssh session so that you can monitor the results. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rtdm over x86_64
Hi Jan
Just a small patch to get the ball rolling with an x86_64 support..
The attached resolves a compile time warning of:
kernel/xenomai/skins/rtdm/core.c: In function ‘_rtdm_ioctl’:
kernel/xenomai/skins/rtdm/core.c:408: warning: comparison is always false due
to limited range of data type
Regards, Paul.
Index: include/rtdm/rtdm.h
===
--- include/rtdm/rtdm.h (revision 2105)
+++ include/rtdm/rtdm.h (working copy)
@@ -248,7 +248,7 @@ int _rtdm_open (rtdm_user_info_t *
int _rtdm_socket (rtdm_user_info_t *user_info, int protocol_family,
int socket_type, int protocol);
int _rtdm_close (rtdm_user_info_t *user_info, int fd, int forced);
-int _rtdm_ioctl (rtdm_user_info_t *user_info, int fd, int request, ...);
+int _rtdm_ioctl (rtdm_user_info_t *user_info, int fd, unsigned int request, ...);
ssize_t _rtdm_read (rtdm_user_info_t *user_info, int fd, void *buf,
size_t nbyte);
ssize_t _rtdm_write (rtdm_user_info_t *user_info, int fd, const void *buf,
Index: ksrc/skins/rtdm/core.c
===
--- ksrc/skins/rtdm/core.c (revision 2105)
+++ ksrc/skins/rtdm/core.c (working copy)
@@ -393,7 +393,7 @@ do {
} while (0)
-int _rtdm_ioctl(rtdm_user_info_t *user_info, int fd, int request, ...)
+int _rtdm_ioctl(rtdm_user_info_t *user_info, int fd, unsigned int request, ...)
{
va_list args;
void*arg;
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Adeos support for 2.6.18 merged PowerPC architecture.
On Thursday 30 November 2006 13:19, Jan Kiszka wrote: > Philippe, I know you are very busy, but shouldn't we make a pre-release > available already, also to discuss further how to deal best with genirq > on other platforms beyond x86? I have an x86_64 box waiting for a Xenomai port - I don't see much point in hacking 2.6.17 and earlier when 2.6.19 is going to be a major change in key areas.. It also looks like there is a closer integration of x86_64 and plain old ix86 code in the 2.6.19 tree, so this may simplify the task of maintaining a 64bit patch. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] 2.6.18 ppc ipipe patch patch
Currently have a G3 Mac on loan and thought it worth trying out a 2.6.18.1
kernel - The prepare-kernel.sh patched without any errors, a few offset lines,
but that is to be expected.. Once configured however, compilation failed with
some fatal errors over ipipe.h and line 223 - It would appear that the
adeos-ipipe patch is adding a malformed line from the preamble of the
following chunk. The ppc-ipipe_fix patch corrects this issue, and the second
attempts to clean up the rest of the patch.
Regards, Paul.
Index: ksrc/arch/powerpc/patches/adeos-ipipe-2.6.18-ppc-1.4-01.patch
===
--- ksrc/arch/powerpc/patches/adeos-ipipe-2.6.18-ppc-1.4-01.patch (revision 1732)
+++ ksrc/arch/powerpc/patches/adeos-ipipe-2.6.18-ppc-1.4-01.patch (working copy)
@@ -1,4 +1,4 @@
-+ diff -u linux-2.6.18/arch/powerpc/kernel/idle.c.ORIG linux-2.6.18/arch/powerpc/kernel/idle.c
+diff -u linux-2.6.18/arch/powerpc/kernel/idle.c.ORIG linux-2.6.18/arch/powerpc/kernel/idle.c
--- linux-2.6.18/arch/powerpc/kernel/idle.c.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/powerpc/kernel/idle.c 2006-09-30 10:14:30.845052232 +0200
@@ -51,6 +51,7 @@
@@ -31,7 +31,7 @@
set_thread_flag(TIF_POLLING_NRFLAG);
} else {
-+ diff -u linux-2.6.18/arch/powerpc/kernel/irq.c.ORIG linux-2.6.18/arch/powerpc/kernel/irq.c
+diff -u linux-2.6.18/arch/powerpc/kernel/irq.c.ORIG linux-2.6.18/arch/powerpc/kernel/irq.c
--- linux-2.6.18/arch/powerpc/kernel/irq.c.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/powerpc/kernel/irq.c 2006-09-24 20:35:04.0 +0200
@@ -68,7 +68,11 @@
@@ -46,7 +46,7 @@
#ifdef CONFIG_PPC32
EXPORT_SYMBOL(__irq_offset_value);
-+ diff -u linux-2.6.18/arch/ppc/Kconfig.ORIG linux-2.6.18/arch/ppc/Kconfig
+diff -u linux-2.6.18/arch/ppc/Kconfig.ORIG linux-2.6.18/arch/ppc/Kconfig
--- linux-2.6.18/arch/ppc/Kconfig.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/Kconfig 2006-09-24 14:02:26.0 +0200
@@ -950,6 +950,8 @@
@@ -58,7 +58,7 @@
config HIGHMEM
bool "High memory support"
-+ diff -u linux-2.6.18/arch/ppc/kernel/entry.S.ORIG linux-2.6.18/arch/ppc/kernel/entry.S
+diff -u linux-2.6.18/arch/ppc/kernel/entry.S.ORIG linux-2.6.18/arch/ppc/kernel/entry.S
--- linux-2.6.18/arch/ppc/kernel/entry.S.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/entry.S 2006-09-30 10:11:25.664204000 +0200
@@ -132,8 +132,23 @@
@@ -204,7 +204,7 @@
+bne+ ret_from_except
+b restore
+#endif /* CONFIG_IPIPE */
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_44x.S.ORIG linux-2.6.18/arch/ppc/kernel/head_44x.S
+diff -u linux-2.6.18/arch/ppc/kernel/head_44x.S.ORIG linux-2.6.18/arch/ppc/kernel/head_44x.S
--- linux-2.6.18/arch/ppc/kernel/head_44x.S.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/head_44x.S 2006-09-24 14:02:26.0 +0200
@@ -427,7 +427,11 @@
@@ -220,7 +220,7 @@
/* Alignment Interrupt */
ALIGNMENT_EXCEPTION
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_4xx.S.ORIG linux-2.6.18/arch/ppc/kernel/head_4xx.S
+diff -u linux-2.6.18/arch/ppc/kernel/head_4xx.S.ORIG linux-2.6.18/arch/ppc/kernel/head_4xx.S
--- linux-2.6.18/arch/ppc/kernel/head_4xx.S.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/head_4xx.S 2006-09-24 14:02:26.0 +0200
@@ -228,6 +228,12 @@
@@ -260,7 +260,7 @@
#if 0
/* NOTE:
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_8xx.S.ORIG linux-2.6.18/arch/ppc/kernel/head_8xx.S
+diff -u linux-2.6.18/arch/ppc/kernel/head_8xx.S.ORIG linux-2.6.18/arch/ppc/kernel/head_8xx.S
--- linux-2.6.18/arch/ppc/kernel/head_8xx.S.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/head_8xx.S 2006-09-24 14:02:26.0 +0200
@@ -186,6 +186,11 @@
@@ -299,7 +299,7 @@
EXCEPTION(0xa00, Trap_0a, unknown_exception, EXC_XFER_EE)
EXCEPTION(0xb00, Trap_0b, unknown_exception, EXC_XFER_EE)
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_booke.h.ORIG linux-2.6.18/arch/ppc/kernel/head_booke.h
+diff -u linux-2.6.18/arch/ppc/kernel/head_booke.h.ORIG linux-2.6.18/arch/ppc/kernel/head_booke.h
--- linux-2.6.18/arch/ppc/kernel/head_booke.h.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/head_booke.h 2006-09-24 14:02:26.0 +0200
@@ -187,6 +187,12 @@
@@ -339,7 +339,7 @@
#define FP_UNAVAILABLE_EXCEPTION \
START_EXCEPTION(FloatingPointUnavailable) \
-+ diff -u linux-2.6.18/arch/ppc/kernel/head_fsl_booke.S.ORIG linux-2.6.18/arch/ppc/kernel/head_fsl_booke.S
+diff -u linux-2.6.18/arch/ppc/kernel/head_fsl_booke.S.ORIG linux-2.6.18/arch/ppc/kernel/head_fsl_booke.S
--- linux-2.6.18/arch/ppc/kernel/head_fsl_booke.S.ORIG 2006-09-20 05:42:06.0 +0200
+++ linux-2.6.18/arch/ppc/kernel/head_fsl_booke.S 2006-09-24 14:02:26.0 +0200
@@ -526,7 +526,11 @@
@@ -354,7 +354,7 @@
/* Alignment Interrupt */
ALIGNMENT_EXCEPTI
Re: [Xenomai-core] Xenomai port on CRIS architecture
Hi Julien On Friday 22 September 2006 07:06, OB wrote: > My reference plateform is a FOX board, which include several GPIO and > even a parallel port-like interface. > http://www.acmesystems.it/?id=4 > > Also, please let me know if anybody has any interest in this projet > (beside me!) I for one would be interested in seeing something, even of it was only some latency test figures.. The FOX board is relatively inexpensive, so if it could deliver reasonable latency figures, it would surely be another contender for embedded control. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] semicolon delimiters & quotes
Hi Gilles On Wednesday 23 August 2006 19:53, Gilles Chanteperdrix wrote: > I never got any error when sticking the semicolon to the last > shell line token. I also read the portable shell rules in autobook and > do not find any mention to such a problem. As for quoting the arguments > of echo, I am pretty sure that it is not needed. You are of course correct on both counts - I got in to the habit of quoting echos (cedit's syntax highlighter would pick up on them) and placing whitespaces either side of semicolons.. If nothing else, it makes the files a little easier to read. Regards, Paul. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] semicolon delimiters & quotes
Hi Folks
Having found a problem with another project where semicolons in a few make
targets were causing the shell to barf, I grepped xenomai trunk for similar
problems. In doing so, I also spotted a few echos where the text wasn't
quoted - A sure fire problem should anyone run the offending rule.
Small patch attached.
Regards, Paul.
Index: configure.in
===
--- configure.in (revision 1484)
+++ configure.in (working copy)
@@ -72,7 +72,7 @@
XENO_TARGET_ARCH=blackfin
XENO_LINUX_ARCH=bfinnommu
XENO_LINUX_INSTALL_TARGET=install
- if test x$enable_shared = xyes; then
+ if test x$enable_shared = xyes ; then
AC_MSG_ERROR([Shared libraries unsupported -- reconfigure passing --disable-shared])
fi
;;
@@ -148,7 +148,7 @@
dnl ARCH support for ARM (default: 4)
-if test $XENO_TARGET_ARCH = arm; then
+if test $XENO_TARGET_ARCH = arm ; then
AC_MSG_CHECKING(for ARM architecture version)
CONFIG_XENO_ARM_ARCH=4
CONFIG_XENO_ARM_SA1100=
@@ -184,27 +184,27 @@
[case "$enableval" in
y | yes) XENO_LINUX_SRCDIR=y ;;
n | no) unset XENO_LINUX_SRCDIR ;;
-*) XENO_LINUX_SRCDIR="`/bin/bash -c \"echo $enableval\"`";;
+*) XENO_LINUX_SRCDIR="`/bin/bash -c \"echo $enableval\"`" ;;
esac])
-if test x"$XENO_LINUX_SRCDIR" = x; then
+if test x"$XENO_LINUX_SRCDIR" = x ; then
AC_MSG_RESULT(no)
else
AC_MSG_RESULT(yes)
AC_MSG_CHECKING(for Linux sources)
if test x"$XENO_LINUX_SRCDIR" = xy; then
candidates="linux-* $srcdir/linux-* $srcdir/linux linux"
- if test x"$cross_compiling" = xno; then
+ if test x"$cross_compiling" = xno ; then
candidates="$candidates /lib/modules/`uname -r`/source /usr/src/linux"
fi
- for dir in $candidates; do
- if test -r $dir/Makefile; then
+ for dir in $candidates ; do
+ if test -r $dir/Makefile ; then
XENO_LINUX_SRCDIR=$dir
- break;
+ break ;
fi
done
fi
- if test x"$XENO_LINUX_SRCDIR" = xy || test ! -r $XENO_LINUX_SRCDIR/Makefile; then
+ if test x"$XENO_LINUX_SRCDIR" = xy || test ! -r $XENO_LINUX_SRCDIR/Makefile ; then
AC_MSG_ERROR([Unable to find Linux kernel sources tree, please pass a valid Linux sources directory to --enable-linux-build])
else
XENO_LINUX_SRCDIR=`cd $XENO_LINUX_SRCDIR && pwd`
@@ -222,16 +222,16 @@
linux_full_version="$linux_base_version$linux_EXTRAVERSION"
if test x"$linux_PATCHLEVEL" = x -o x"$linux_SUBLEVEL" = x ||
-test x"$linux_VERSION" = x; then
+test x"$linux_VERSION" = x ; then
AC_MSG_ERROR([Unable to get version of $XENO_LINUX_SRCDIR, aborting.])
else
AC_MSG_RESULT([$XENO_LINUX_SRCDIR (kernel ${linux_full_version})])
fi
case "$linux_base_version" in
- 2.4.*) XENO_LINUX_ALL_TARGETS="bzImage modules";;
+ 2.4.*) XENO_LINUX_ALL_TARGETS="bzImage modules" ;;
2.6.*) XENO_LINUX_ALL_TARGETS="all";;
- *) AC_MSG_ERROR([Unknown Linux version $linux_full_version]);;
+ *) AC_MSG_ERROR([Unknown Linux version $linux_full_version]) ;;
esac
AC_SUBST(XENO_LINUX_ALL_TARGETS)
AC_SUBST(XENO_LINUX_INSTALL_TARGET)
@@ -245,11 +245,11 @@
patch. Default is to infer the patch name from Linux kernel version.]),
[ADEOS_PATCH="`/bin/bash -c \"echo $withval\"`"])
- if test x"$ADEOS_PATCH" = x && test x"$linux_base_version" != x; then
+ if test x"$ADEOS_PATCH" = x && test x"$linux_base_version" != x ; then
set -- $srcdir/ksrc/arch/$XENO_TARGET_ARCH/patches/adeos-*$linux_base_version-$XENO_LINUX_ARCH-*
ADEOS_PATCH=$1
fi
- if test x"$ADEOS_PATCH" = x || test ! -e $ADEOS_PATCH; then
+ if test x"$ADEOS_PATCH" = x || test ! -e $ADEOS_PATCH ; then
AC_MSG_ERROR([Unable to find Adeos patch, please use --with-adeos-patch])
else
AC_MSG_RESULT([$ADEOS_PATCH])
@@ -257,10 +257,10 @@
AC_SUBST(ADEOS_PATCH)
AC_CONFIG_COMMANDS(linux, [
- if test -e linux/.xenomai-prepared; then
+ if test -e linux/.xenomai-prepared ; then
. linux/.xenomai-prepared
if test x"$XENO_LINUX_VERSION" != x"$PREPARED_LINUX_VERSION" ||
- test x"`basename $ADEOS_PATCH`" != x"$PREPARED_ADEOS_PATCH"; then
+ test x"`basename $ADEOS_PATCH`" != x"$PREPARED_ADEOS_PATCH" ; then
echo "*** Warning: built version of linux and requested versions are "
echo "*** different. If you want to build the requested version of "
echo "*** linux,
Re: [Xenomai-core] Future of fusion
Hi Philippe On Thursday 13 October 2005 09:24, Philippe Gerum wrote: > - Regular automated benchmarking: What is Xenomai currently capable of, how > stable is it, do we progress or regress over time and releases, arch by > arch? Have a couple of x86 development boxes running 24/7 - Could set one up as a compile farm for running automated builds. Also have a PowerPC thin client that I would like to utilise, but could really do with some help in setting up the tools for cross-compiling the base system under Debian. > - Configuration, building and packaging issues: Could we make this easier? Anything that involves patching/compiling kernels is bound to cause trouble for new users. Perhaps some tests for kernel options known to cause trouble (such as APM & REGPARM) that print out large warnings during the config stage might help.. Gilles already has a tarball of the Debian rules I used for packaging fusion. With minor changes, these could be used for a Xenomai package. One possibility is to use the rules and the compile farm to produce "ready to run" kernel/Xenomai Debian packages. Regards, Paul. -- From the Klingon book of C: Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
