[Xenomai-core] [PATCH] debian: update debian/control for debian 6.0 squeeze
Hi,
patch attached for upcoming debian 6.0 squeeze.
Stefan
From 505640995eac8b64b53a9fab476c9f91203be6ab Mon Sep 17 00:00:00 2001
From: Stefan Kisdaroczi ki...@hispeed.ch
Date: Mon, 3 Jan 2011 14:07:57 +0100
Subject: [PATCH 1/2] debian: update debian/control for debian 6.0 squeeze
---
debian/control | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/debian/control b/debian/control
index ab4636d..5505d2c 100644
--- a/debian/control
+++ b/debian/control
@@ -3,13 +3,13 @@ Section: devel
Priority: extra
Maintainer: Roland Stigge sti...@antcom.de
Build-Depends: debhelper (= 7), dh-kpatches, findutils (= 4.2.28)
-Standards-Version: 3.8.0
+Standards-Version: 3.9.1
Homepage: http://www.xenomai.org/
Package: xenomai-runtime
Section: devel
Architecture: amd64 arm armeb armel i386 powerpc
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: linux-patch-xenomai, xenomai-doc
Replaces: xenomai
Conflicts: xenomai
@@ -25,9 +25,9 @@ Description: Xenomai runtime utilities
realtime system.
Package: linux-patch-xenomai
-Section: devel
+Section: kernel
Architecture: all
-Depends: ${kpatch:Depends}
+Depends: ${kpatch:Depends}, ${misc:Depends}
Suggests: xenomai, linux-source-2.6, kernel-package
Description: Linux kernel patches for Xenomai
Xenomai is a real-time development framework cooperating with the Linux
@@ -48,7 +48,7 @@ Description: Linux kernel patches for Xenomai
Package: libxenomai1
Section: libs
Architecture: amd64 arm armeb armel i386 powerpc
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: linux-patch-xenomai, xenomai-doc
Replaces: xenomai
Conflicts: xenomai
@@ -65,7 +65,7 @@ Description: Shared libraries for Xenomai
Package: libxenomai-dev
Section: libdevel
Architecture: amd64 arm armeb armel i386 powerpc
-Depends: libxenomai1 (= ${binary:Version})
+Depends: libxenomai1 (= ${binary:Version}), ${misc:Depends}
Suggests: linux-patch-xenomai, xenomai-doc
Replaces: xenomai
Conflicts: xenomai
@@ -83,7 +83,7 @@ Description: Headers and static libs for Xenomai
Package: xenomai-doc
Section: doc
Architecture: all
-Depends:
+Depends: ${misc:Depends}
Suggests: xenomai
Conflicts: xenomai-docs
Replaces: xenomai-docs
--
1.7.2.3
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] debian: update debian/cont rol for debian 6.0 squeeze
Am Montag 03 Januar 2011, 21:22:44 schrieb Gilles Chanteperdrix: Stefan Kisdaroczi wrote: Hi, patch attached for upcoming debian 6.0 squeeze. Does not it create an artificial limitation? I mean, does not it prevent us from building Xenomai with an older version? I tested the package building with old debian 5.0 lenny, works still fine. Stefan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [announce] Xenomai v2.5.5
Hi Gilles, On 06.10.2010 14:05, Gilles Chanteperdrix wrote: [...] - the debian patch generation script, which caused invalid patches to be generated for recent kernel releases The file scripts/prepare-patch.sh is missing in the xenomai-2.5.5.tar.bz2 archive. Stefan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [announce] Xenomai v2.5.5
On 06.10.2010 16:24, Gilles Chanteperdrix wrote: Stefan Kisdaroczi wrote: Hi Gilles, On 06.10.2010 14:05, Gilles Chanteperdrix wrote: [...] - the debian patch generation script, which caused invalid patches to be generated for recent kernel releases The file scripts/prepare-patch.sh is missing in the xenomai-2.5.5.tar.bz2 archive. I do not see it in scripts/Makefile.am EXTRA_DIST. Did I miss some part of your patch? No. I missed that in the patch, I just moved the file from debian/ to scripts/. Sorry, but a stupid guy like me simply does not understand why a script in a git tree needs to be put in a Makefile.am so that it gets put in a archive from that tree. If I do git archive v2.5.5 | bzip2 ... it works. The only difference between the archives is the inclusion of the 3 pdf's in the doc/nodist dir and the 3 small scripts in scripts/maint directory (and prepare-patch.sh). The pdf's could be put out of the tree, but simple solutions and workflows are probably just for stupid people like me. Stefan (annoyed) signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [git pull] small RTDM fixes and assorted patches
Hi Jan, https://mail.gna.org/public/xenomai-core/2010-05/msg00059.html Stefan Am 20.08.2010 17:02, schrieb Jan Kiszka: The following changes since commit 7e2735614ebe515d57abeaa3ff6df375a7c4149f: sched: avoid infinite reschedule loops (2010-08-03 00:11:21 +0200) are available in the git repository at: git://git.xenomai.org/xenomai-jki.git for-upstream Jan Kiszka (8): rt_print: Properly return printed length RTDM: Protect xnshadow_ppd_get via nklock RTDM: Plug race between proc_read_dev_info and device deregistration RTDM: Properly clean up on xnvfile setup errors RTDM: Extend device name space in open_fildes proc output Fix symbolic status ouput of root threads Create watchdog as non-blockable timer native: Improve documentation of rt_task_join and rt_task_delete ksrc/nucleus/sched.c |3 ++- ksrc/nucleus/thread.c|4 ksrc/skins/native/task.c | 15 +-- ksrc/skins/rtdm/core.c |2 ++ ksrc/skins/rtdm/proc.c | 45 +++-- src/rtdk/rt_print.c |1 + 6 files changed, 57 insertions(+), 13 deletions(-) The bug fixes (patches 1-4 and 7) should all be considered for 2.5 as well, but some need rebasing. Will look into this once the series is acceptable. Jan ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] RTDM device profiles: Document open_rt, socket_rt and close_rt deprecation
regards, stefan From e8459dc079118f9f635ef31c996019a0652e4907 Mon Sep 17 00:00:00 2001 From: Stefan Kisdaroczi ki...@hispeed.ch Date: Wed, 19 May 2010 11:31:00 +0200 Subject: [PATCH] RTDM device profiles: Document open_rt, socket_rt and close_rt deprecation --- include/rtdm/rtcan.h |4 ++-- include/rtdm/rtserial.h |4 ++-- include/rtdm/rttesting.h |4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/rtdm/rtcan.h b/include/rtdm/rtcan.h index 43399e2..34a2044 100644 --- a/include/rtdm/rtcan.h +++ b/include/rtdm/rtcan.h @@ -59,7 +59,7 @@ * @par Supported Operations * @n * @b Socket @n - * Environments: non-RT (RT optional)@n + * Environments: non-RT (RT optional, deprecated)@n * @n * Specific return values: * - -EPROTONOSUPPORT (Protocol is not supported by the driver. @@ -72,7 +72,7 @@ * Blocking calls to any of the @ref Send or @ref Recv Receive functions * will be unblocked when the socket is closed and return with an error. @n * @n - * Environments: non-RT (RT optional)@n + * Environments: non-RT (RT optional, deprecated)@n * @n * Specific return values: none @n * @n diff --git a/include/rtdm/rtserial.h b/include/rtdm/rtserial.h index 48712b2..00dc536 100644 --- a/include/rtdm/rtserial.h +++ b/include/rtdm/rtserial.h @@ -42,11 +42,11 @@ * * @par Supported Operations * @b Open @n - * Environments: non-RT (RT optional)@n + * Environments: non-RT (RT optional, deprecated)@n * Specific return values: none @n * @n * @b Close @n - * Environments: non-RT (RT optional)@n + * Environments: non-RT (RT optional, deprecated)@n * Specific return values: none @n * @n * @b IOCTL @n diff --git a/include/rtdm/rttesting.h b/include/rtdm/rttesting.h index e936630..a3a7ae9 100644 --- a/include/rtdm/rttesting.h +++ b/include/rtdm/rttesting.h @@ -43,11 +43,11 @@ * * @par Supported Operations * @b Open @n - * Environments: non-RT (RT optional)@n + * Environments: non-RT (RT optional, deprecated)@n * Specific return values: none @n * @n * @b Close @n - * Environments: non-RT (RT optional)@n + * Environments: non-RT (RT optional, deprecated)@n * Specific return values: none @n * @n * @b IOCTL @n -- 1.7.0.4 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rtdm_dev_register oops
hi,
i got a exception in rtdm_dev_register(). I didnt call rtdm_dev_unregister in
my driver
and after insmodding the module again I got a oops.
xenomai 2.5.3, linux 2.6.32.11, x86 32bit, ubuntu 10.04.
Attached is the dmesg-trace and a small rtdm-module foo.c for reproduction:
insmod ./xeno_foo.ko
rmmod xeno_foo
insmod ./xeno_foo.ko - oops
thanks
stefan
UNAME := $(shell uname -r)
PWD := $(shell pwd)
LINUXSOURCEDIR:= /usr/src/linux-headers-$(UNAME)
obj-m := xeno_foo.o
xeno_foo-y:= foo.o
EXTRA_CFLAGS := -I/usr/src/linux-headers-$(UNAME)/include/xenomai
all::
$(MAKE) -C $(LINUXSOURCEDIR) SUBDIRS=$(PWD) modules
clean::
$(RM) .*.cmd *.cmd *.o *.ko *.mod.c *.order *.symvers
$(RM) -R .tmp*
.PHONY: clean
#include linux/module.h
#include rtdm/rtdm_driver.h
MODULE_AUTHOR( Stefan Kisdaroczi );
MODULE_LICENSE( GPL );
int foo_open_nrt( struct rtdm_dev_context *context,
rtdm_user_info_t *user_info,
int oflags ) {
return 0;
}
int foo_close_nrt( struct rtdm_dev_context *context,
rtdm_user_info_t *user_info ) {
return 0;
}
struct rtdm_device foo_rtdm_device = {
device_flags: RTDM_NAMED_DEVICE,
device_class: RTDM_CLASS_EXPERIMENTAL,
device_sub_class: RTDM_SUBCLASS_GENERIC,
device_name:foo0,
proc_name: foo0,
device_id: 0,
open_nrt : foo_open_nrt,
ops: {
close_nrt: foo_close_nrt,
},
};
int __init foo_init( void ) {
return rtdm_dev_register( foo_rtdm_device );
}
void __exit foo_exit( void ) {
/* rtdm_dev_unregister( foo_rtdm_device, 1000 ); */
}
module_init( foo_init );
module_exit( foo_exit );
[ 185.000326] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 185.000340] IP: [c01f873a] rtdm_dev_register+0x2ea/0x470
[ 185.000358] *pde =
[ 185.000365] Oops: [#1] SMP
[ 185.000373] last sysfs file:
/sys/devices/pci:00/:00:02.0/:01:00.2/:03:0d.0/host4/target4:0:1/4:0:1:0/block/sdb/uevent
[ 185.000381] Modules linked in: xeno_foo(+) snd_intel8x0 snd_ac97_codec
ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy hisax crc_ccitt isdn
snd_seq_oss com20020_pci snd_seq_midi snd_rawmidi snd_seq_midi_event com20020
arcnet snd_seq snd_timer snd_seq_device psmouse e752x_edac snd shpchp ppdev
soundcore serio_raw edac_core snd_page_alloc lp dcdbas parport_pc parport
usbhid floppy hid aic79xx e1000 scsi_transport_spi [last unloaded: xeno_foo]
[ 185.000468]
[ 185.000476] Pid: 2216, comm: insmod Not tainted (2.6.32.11-xenomai-2.5.3 #2)
Precision WorkStation 470
[ 185.000483] EIP: 0060:[c01f873a] EFLAGS: 00210202 CPU: 0
[ 185.000491] EIP is at rtdm_dev_register+0x2ea/0x470
[ 185.000498] EAX: 0001 EBX: 03a0 ECX: 03a0 EDX: f832e06c
[ 185.000503] ESI: EDI: f833f06c EBP: f6595f54 ESP: f6595f34
[ 185.000509] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 185.000515] Process insmod (pid: 2216, ti=f6594000 task=ecc1b340
task.ti=f6594000)
[ 185.000520] I-pipe domain Linux
[ 185.000524] Stack:
[ 185.000528] c019ba17 f6595f54 c059b953 f833f060 03a0 fffc f833f120
[ 185.000544] 0 f6595f5c f834200d f6595f88 c0101132 f833f120 c07723a0
fffc f833f120
[ 185.000563] 0 b7815ff4 f8342000 fffc f833f120 b7815ff4 f6595fac
c0175371 00200046
[ 185.000583] Call Trace:
[ 185.000594] [c019ba17] ? tracepoint_module_notify+0x27/0x30
[ 185.000605] [c059b953] ? notifier_call_chain+0x43/0x60
[ 185.000616] [f834200d] ? foo_init+0xd/0xf [xeno_foo]
[ 185.000627] [c0101132] ? do_one_initcall+0x32/0x1b0
[ 185.000636] [f8342000] ? foo_init+0x0/0xf [xeno_foo]
[ 185.000648] [c0175371] ? sys_init_module+0xb1/0x220
[ 185.000657] [c0103145] ? sysenter_do_call+0x12/0x16
[ 185.000663] Code: bf 92 c0 21 f1 c1 e1 03 89 4d f0 01 c8 8b 30 8b 16 0f 18
02 90 39 f0 0f 84 c8 00 00 00 89 5d ec 89 cb eb 1c 90 8d 74 26 00 8b 36 8b 06
0f 18 00 90 a1 c0 bf 92 c0 01 d8 39 c6 0f 84 a2 00 00 00
[ 185.000756] EIP: [c01f873a] rtdm_dev_register+0x2ea/0x470 SS:ESP
0068:f6595f34
[ 185.000767] CR2:
[ 185.000772] ---[ end trace dbaf656208b2cc62 ]---
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rtdm_dev_register oops
Am 18.05.2010 13:03, schrieb Jan Kiszka: Stefan Kisdaroczi wrote: hi, i got a exception in rtdm_dev_register(). I didnt call rtdm_dev_unregister in my driver and after insmodding the module again I got a oops. And that is surprising to you? :) A bit. If you leave the previous device registered on rmmod, oopses are programmed to occur: You leave references to unallocated memory behind. If one device fails to unregister i can't register any other device anymore, the rtdm registry is broken (cat /proc/xenomai/rtdm/names_devices hangs). That was surprising. If I have one corrupt file on my disk i can still create/access other files or list the filenames without exception. Please don't get me wrong, but its not obvious for me that a registry behaves like that, but i can life with it. Sorry for the noise. Stefan Jan xenomai 2.5.3, linux 2.6.32.11, x86 32bit, ubuntu 10.04. Attached is the dmesg-trace and a small rtdm-module foo.c for reproduction: insmod ./xeno_foo.ko rmmod xeno_foo insmod ./xeno_foo.ko - oops thanks stefan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] New Debian source package format 3.0
Gilles Chanteperdrix schrieb: Roland Stigge wrote: Hi, * To migrate appropriately, you can do the following changes in the xenomai.org repository: $ mkdir debian/source $ echo '3.0 (native)' debian/source/format $ dch 'Switch to dpkg-source 3.0 (native) format' It is OK with me, but I probably do not have the proper tools installed. Could someone do it and send me the patches? Stefan maybe? TIA. patch attached, stefan From fa86da573916f59869e6f2e552525d9f9c4135de Mon Sep 17 00:00:00 2001 From: Stefan Kisdaroczi ki...@hispeed.ch Date: Sun, 16 May 2010 21:48:34 +0200 Subject: [PATCH] debian: switch to dpkg-source 3.0 (native) format --- debian/changelog |6 ++ debian/source/format |1 + debian/watch |2 -- 3 files changed, 7 insertions(+), 2 deletions(-) create mode 100644 debian/source/format delete mode 100644 debian/watch diff --git a/debian/changelog b/debian/changelog index 9f001a9..c69851e 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +xenomai (2.5.3) unstable; urgency=low + + * Switch to dpkg-source 3.0 (native) format + + -- Stefan Kisdaroczi ki...@hispeed.ch Sun, 16 May 2010 21:46:58 +0200 + xenomai (2.5.2-2) unstable; urgency=low * Added patch from Stefan Kisdaroczi ki...@hispeed.ch: diff --git a/debian/source/format b/debian/source/format new file mode 100644 index 000..89ae9db --- /dev/null +++ b/debian/source/format @@ -0,0 +1 @@ +3.0 (native) diff --git a/debian/watch b/debian/watch deleted file mode 100644 index caf6853..000 --- a/debian/watch +++ /dev/null @@ -1,2 +0,0 @@ -version=3 -http://download.gna.org/xenomai/stable/xenomai-(.*)\.tar\.bz2 -- 1.5.6.5 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] debian: sync with 2.5.2-2 from debian.org,
Am 03.05.2010 20:46, schrieb Gilles Chanteperdrix: Stefan Kisdaroczi wrote: Hi Philippe, Roland Stigge has accepted the group xenomai patch and uploaded xenomai 2.5.2-2 to debian unstable. I have attached a patch against rpm/for-upstream to sync up with 2.5.2-2. Please ignore other patches I sent earlier, the attached patch contains them. Thanks. Reading your patch, maybe libxenomai.so.0 should be called libxenomai.so.1 ? The comment in the libxenomai1.lintian hunk was added by Roland, so it's probably better to ask him. Roland, what do you think ? Stefan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] debian: sync with 2.5.2-2 from debian.org,
Hi Philippe, Roland Stigge has accepted the group xenomai patch and uploaded xenomai 2.5.2-2 to debian unstable. I have attached a patch against rpm/for-upstream to sync up with 2.5.2-2. Please ignore other patches I sent earlier, the attached patch contains them. Thanks. Stefan From 1cde4f3c8a6d84ad1fc043682fa282fea809a228 Mon Sep 17 00:00:00 2001 From: Stefan Kisdaroczi ki...@hispeed.ch Date: Mon, 3 May 2010 10:37:09 +0200 Subject: [PATCH] debian: sync with 2.5.2-2 from debian.org --- debian/changelog| 17 + debian/libxenomai1.dirs |1 + debian/libxenomai1.lintian |7 ++- debian/libxenomai1.modprobe |3 +++ debian/libxenomai1.postinst | 20 ++-- debian/libxenomai1.xenomai.init |1 - debian/rules|2 ++ debian/xenomai-runtime.install |1 + 8 files changed, 48 insertions(+), 4 deletions(-) create mode 100644 debian/libxenomai1.modprobe diff --git a/debian/changelog b/debian/changelog index 6d2d3cf..9f001a9 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,20 @@ +xenomai (2.5.2-2) unstable; urgency=low + + * Added patch from Stefan Kisdaroczi ki...@hispeed.ch: +- Create group xenomai on install +- Added a init-script which sets /sys/.../xenomai_gid if + /sys/.../xenomai_gid exists +- Added a modprobe-script that adds the xenomai_gid parameter if the user + did call modprobe without xenomai_gid= + + -- Roland Stigge sti...@antcom.de Sun, 02 May 2010 17:06:14 +0200 + +xenomai (2.5.2-1) unstable; urgency=low + + * New upstream release + + -- Roland Stigge sti...@antcom.de Mon, 29 Mar 2010 20:51:07 +0200 + xenomai (2.5.1-4) unstable; urgency=low * Added patches by Stefan Kisdaroczi ki...@hispeed.ch: diff --git a/debian/libxenomai1.dirs b/debian/libxenomai1.dirs index 1737ea1..35f4b51 100644 --- a/debian/libxenomai1.dirs +++ b/debian/libxenomai1.dirs @@ -1,2 +1,3 @@ +etc/modprobe.d etc/udev/rules.d usr/share/lintian/overrides diff --git a/debian/libxenomai1.lintian b/debian/libxenomai1.lintian index fe0da46..f5694a3 100644 --- a/debian/libxenomai1.lintian +++ b/debian/libxenomai1.lintian @@ -1,2 +1,7 @@ -# no contained shared library names refer to xenomai, therefore own name +# The package libxenomai1 first didn't contain a library called *xenomai*. +# Therefore, I called it libxenomai1. Now, upstream introduced libxenomai0 in +# the package. I'm leaving the package name libxenomai1 for now since +# downgrading the number in the package name is probably a bad idea, and +# synchronizing the package name with the SO version number isn't easily +# possible anyway since the package contains several libraries. libxenomai1: package-name-doesnt-match-sonames libanalogy1 libnative3 libpsos0 libpthread-rt1 librtai0 librtdk0 librtdm1 libuitron0 libvrtx0 libvxworks1 libxenomai0 diff --git a/debian/libxenomai1.modprobe b/debian/libxenomai1.modprobe new file mode 100644 index 000..1953854 --- /dev/null +++ b/debian/libxenomai1.modprobe @@ -0,0 +1,3 @@ +install xeno_nucleus /sbin/modprobe --ignore-install xeno_nucleus $CMDLINE_OPTS \ + $(/usr/bin/test $(/bin/echo -n '$CMDLINE_OPTS' | /bin/grep xenomai_gid) \ +|| /usr/bin/getent group xenomai | /usr/bin/cut -d: -f3 | /bin/sed -e 's/^/xenomai_gid\=/') diff --git a/debian/libxenomai1.postinst b/debian/libxenomai1.postinst index 8afc6fc..97c3476 100644 --- a/debian/libxenomai1.postinst +++ b/debian/libxenomai1.postinst @@ -1,6 +1,22 @@ #!/bin/sh -e -rm -f /etc/udev/rules.d/xenomai.rules -ln -sf ../xenomai.rules /etc/udev/rules.d/xenomai.rules +case $1 in +configure) +# Add the xenomai group unless it's already there +if ! getent group xenomai /dev/null; then +addgroup --quiet --system xenomai || true +fi +rm -f /etc/udev/rules.d/xenomai.rules +ln -sf ../xenomai.rules /etc/udev/rules.d/xenomai.rules +;; + +abort-upgrade|abort-remove|abort-deconfigure) +;; + +*) +echo postinst called with unknown argument \`$1' 2 +exit 1 +;; +esac #DEBHELPER# diff --git a/debian/libxenomai1.xenomai.init b/debian/libxenomai1.xenomai.init index ebb5092..e243b5e 100644 --- a/debian/libxenomai1.xenomai.init +++ b/debian/libxenomai1.xenomai.init @@ -24,7 +24,6 @@ case $1 in echo -1 $FILENAME ;; restart|force-reload) -$0 stop $0 start ;; *) diff --git a/debian/rules b/debian/rules index 4cb53a3..e39977d 100755 --- a/debian/rules +++ b/debian/rules @@ -38,6 +38,7 @@ endif CONFIG_OPTS += --prefix=/usr \ --includedir=/usr/include/xenomai \ --mandir=/usr/share/man \ + --with-testdir=/usr/lib/xenomai ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) CONFIG_OPTS += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) @@ -97,6 +98,7 @@ install: build for f in $(CURDIR)/ksrc/nucleus
[Xenomai-core] [PATCH] debian: sync with 2.5.2-1 from debian.org
patch against rpm/for-upstream Stefan From 68882152f383e36ecde8cbb3e0f6474deb64197b Mon Sep 17 00:00:00 2001 From: Stefan Kisdaroczi ki...@hispeed.ch Date: Thu, 15 Apr 2010 11:11:26 +0200 Subject: [PATCH] debian: sync with 2.5.2-1 from debian.org --- debian/changelog |6 ++ debian/libxenomai1.lintian |7 ++- debian/rules |1 + debian/xenomai-runtime.install |1 + 4 files changed, 14 insertions(+), 1 deletions(-) diff --git a/debian/changelog b/debian/changelog index 6d2d3cf..3e4a44b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +xenomai (2.5.2-1) unstable; urgency=low + + * New upstream release + + -- Roland Stigge sti...@antcom.de Mon, 29 Mar 2010 20:51:07 +0200 + xenomai (2.5.1-4) unstable; urgency=low * Added patches by Stefan Kisdaroczi ki...@hispeed.ch: diff --git a/debian/libxenomai1.lintian b/debian/libxenomai1.lintian index fe0da46..f5694a3 100644 --- a/debian/libxenomai1.lintian +++ b/debian/libxenomai1.lintian @@ -1,2 +1,7 @@ -# no contained shared library names refer to xenomai, therefore own name +# The package libxenomai1 first didn't contain a library called *xenomai*. +# Therefore, I called it libxenomai1. Now, upstream introduced libxenomai0 in +# the package. I'm leaving the package name libxenomai1 for now since +# downgrading the number in the package name is probably a bad idea, and +# synchronizing the package name with the SO version number isn't easily +# possible anyway since the package contains several libraries. libxenomai1: package-name-doesnt-match-sonames libanalogy1 libnative3 libpsos0 libpthread-rt1 librtai0 librtdk0 librtdm1 libuitron0 libvrtx0 libvxworks1 libxenomai0 diff --git a/debian/rules b/debian/rules index 4cb53a3..38991e2 100755 --- a/debian/rules +++ b/debian/rules @@ -38,6 +38,7 @@ endif CONFIG_OPTS += --prefix=/usr \ --includedir=/usr/include/xenomai \ --mandir=/usr/share/man \ + --with-testdir=/usr/lib/xenomai ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) CONFIG_OPTS += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) diff --git a/debian/xenomai-runtime.install b/debian/xenomai-runtime.install index c9eee75..d1dbe13 100644 --- a/debian/xenomai-runtime.install +++ b/debian/xenomai-runtime.install @@ -2,3 +2,4 @@ usr/bin usr/sbin usr/share/man usr/share/xenomai +usr/lib/xenomai -- 1.5.6.5 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] proc_file_read: Apparent buffer overflow
Am 10.03.2010 19:56, schrieb Stefan Kisdaroczi: Hi, cat /proc/xenomai/heap returns the first 4096 Bytes and fails then with Bad address. On the console I see: proc_file_read: Apparent buffer overflow! xeno 2.5.1, linux 2.6.32.8, x86 32bit UP, native skin, lot of rt_queues: # ls -1 /proc/xenomai/registry/native/queues/ | wc -l 233 # ls -1 /proc/xenomai/registry/native/heaps/ | wc -l 26 With some luck i get a oops doing cat /proc/xenomai/heap. Looking at the while() loop in heap_read_proc() in ksrc/nucleus/heap.c its obvious. Stefan 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 in Debian
Am 26.02.2010 15:07, schrieb Philippe Gerum: On Fri, 2010-02-26 at 14:48 +0100, Stefan Kisdaroczi wrote: Am 26.02.2010 14:28, schrieb Philippe Gerum: On Fri, 2010-02-26 at 14:13 +0100, Stefan Kisdaroczi wrote: Am 24.02.2010 14:13, schrieb Philippe Gerum: On Wed, 2010-02-24 at 14:11 +0100, Philippe Gerum wrote: On Wed, 2010-02-24 at 14:06 +0100, Stefan Kisdaroczi wrote: Hi Philippe, Am 23.02.2010 18:46, schrieb Philippe Gerum: On Tue, 2010-02-23 at 17:52 +0100, Stefan Kisdaroczi wrote: Hi, Am 14.02.2010 10:38, schrieb Philippe Gerum: snip In the future, maybe we could simply provide a wrapper script accepting sub-commands, such as xeno latency, xeno sigtest etc, to be put into /usr/bin by distros, which would hide the actual location of those binaries? In any case, thanks for your work so far. We probably need to discuss the packaging issues on this list, so that we get both consistency and usability in the future. Gilles and Roland, if this is fine with you, I'll handle the liaison role with upstream packagers, so please CC me explicitly on those mails. We'll sort out this issue, it doesn't look that bad anyway. Roland added a xeno wrapper to the debian.org xenomai package 2.5.1-3. I synced now the debian/ directories from debian.org and xenomai.org: - For debian.org I sent patches to the Debian bugtracker [1] [2]. Another patch for dpkg-cross support [3] I sent to Roland privately. - For xenomai.org I attached patches to this mail (against -2.5.git). If both parties apply the patches the debian directories are in sync, except some minor differences in the debian/control file, see patch do-not-commit-please.patch. I would like to keep these changes out so that the xenomai.org packages are compatible with Debian 5.0 Lenny. The debian.org packages are for Debian 6.0 Squeeze. Merged into my queue (except the last one as mentioned). This will be pushed upstream to Gilles for 2.5.2. Thanks. I took a look at your branch for-upstream. Your commit scripts: add wrapper script to run standard Xenomai commands 6e0574791f48cbf8b3421a68c5789254e7d084b7 adds the same wrapper as my patch 0005-debian-wrapper-script-usr-bin-xeno-to-call-executa.patch debian: wrapper script /usr/bin/xeno to call executables in /usr/lib/xenomai/ fbe86cc50d3a65cd23e93d43adba4ed369fe70b1 Please revert the commit of my patch, we need another fix for debian/rules for your wrapper. Ok, I thought your patch set was based on my tree, so I did not check thoroughly. I did not send any pull request to Gilles, so no harm done. How do I call configure to install the wrapper in /usr/bin and the programs like latency, switchtest etc. to /usr/lib/xenomai ? We need some fixage in scripts/wrappers/Makefile.am to do that. I'll prepare this asap. scripts/Makefile.am... Hi Philippe, I just tried the --with-testdir switch. It worked, but i'm not really sure if this is the right track. Roland's packages install all binaries to /usr/lib/xenomai, except xeno and xeno-config. You state in your commit message more or less the same goal: At some point, all remaining executables or scripts left under $prefix/bin should match xeno*, to further reduce the odds of causing name collisions. Using --with-testdir all tests (latency,switchtest,...) are now in /usr/lib/xenomai. To install the utils (rtcansend,insn_write,insn_write,cmd_read,...) to the same directory using --with-testdir sounds not obviously. You could add a second switch --with-utildir, but a second dir will not work for the xeno-wrapper-script. CAN and other utilities should definitely remain in $bindir. The fact that they are not prefixed by xeno* is another thing; CAN utilities are already prefixed, maybe Analogy ones should be named in a bit less generic way, although they are not raising any conflict today. I wrote that what's under $bindir should match xeno* when a risk of collision exists, but there is no point in enforcing a stricter rule at this point. In any case, I don't want to enforce a never-in-bindir rule for all Xenomai binaries, we can still pick their names in a way that avoids obvious issues. The real problem was about tests, for which using rather generic names made sense. This is what that patch is for. ok, got the goal now, thanks for the explanation. But xeno.in needs a fix to use @XENO_TEST_DIR@, no? Yes, I overlooked that. In fact, I think we may not even need the new xeno wrapper at all, but we probably want to rewrite xeno-test to wrap to what is in XENO_TEST_DIR now. I would suggest to hold the changes to the debian/ area for now, until Agree with holding back wrapper-changes, but please consider the attached patch with small fixes, thanks. (against rpm/for-upstream) the dust has settled a bit. We are trying to fix long-standing problems in the way we allow people to test their setup. I think something like using --bindir=/usr/lib
Re: [Xenomai-core] Xenomai in Debian
Am 25.02.2010 18:18, schrieb Stefan Kisdaroczi:
snip
Hi Gilles,
can a init.d script with
echo gid /sys/module/xeno_nucleus/parameters/xenomai_gid
work in module and builtin case ?
it seems that init.d will work for the builtin case and modprobe.d for the
module case. So adding both should work in all cases :-)
I'll give it a try ...
Attached a patch that adds a init-script /etc/init.d/xenomai to the package
libxenomai1.
If group xenomai and the file /sys/module/xeno_nucleus/parameters/xenomai_gid
are found,
xenomai_gid is set on startup.
Now looking at modprobe.d ...
I have attached a patch against debian xenomai version 2.5.1-4, changes:
- create group xenomai on install
- added a init-script which sets /sys/.../xenomai_gid if
/sys/.../xenomai_gid exists
- added a modprobe-script that adds the xenomai_gid parameter if the user
did call modprobe without xenomai_gid=
With this changes, all users which are member of the group xenomai are able
to run xenomai apps, with xeno_nucleus builtin or as a module.
Please do not merge anywhere for now, comments are welcome.
Stefan
diff -uNrp xenomai-2.5.1.orig/debian/libxenomai1.dirs
xenomai-2.5.1/debian/libxenomai1.dirs
--- xenomai-2.5.1.orig/debian/libxenomai1.dirs 2010-02-26 01:01:07.0
+0100
+++ xenomai-2.5.1/debian/libxenomai1.dirs 2010-02-26 01:16:13.0
+0100
@@ -1,2 +1,3 @@
+etc/modprobe.d
etc/udev/rules.d
usr/share/lintian/overrides
diff -uNrp xenomai-2.5.1.orig/debian/libxenomai1.modprobe
xenomai-2.5.1/debian/libxenomai1.modprobe
--- xenomai-2.5.1.orig/debian/libxenomai1.modprobe 1970-01-01
01:00:00.0 +0100
+++ xenomai-2.5.1/debian/libxenomai1.modprobe 2010-02-26 01:07:41.0
+0100
@@ -0,0 +1,3 @@
+install xeno_nucleus /sbin/modprobe --ignore-install xeno_nucleus
$CMDLINE_OPTS \
+ $(/usr/bin/test $(/bin/echo -n '$CMDLINE_OPTS' | /bin/grep xenomai_gid) \
+|| /usr/bin/getent group xenomai | /usr/bin/cut -d: -f3 | /bin/sed -e
's/^/xenomai_gid\=/')
diff -uNrp xenomai-2.5.1.orig/debian/libxenomai1.postinst
xenomai-2.5.1/debian/libxenomai1.postinst
--- xenomai-2.5.1.orig/debian/libxenomai1.postinst 2010-02-26
01:01:07.0 +0100
+++ xenomai-2.5.1/debian/libxenomai1.postinst 2010-02-26 01:06:00.0
+0100
@@ -1,6 +1,22 @@
#!/bin/sh -e
-rm -f /etc/udev/rules.d/xenomai.rules
-ln -sf ../xenomai.rules /etc/udev/rules.d/xenomai.rules
+case $1 in
+configure)
+# Add the xenomai group unless it's already there
+if ! getent group xenomai /dev/null; then
+addgroup --quiet --system xenomai || true
+fi
+rm -f /etc/udev/rules.d/xenomai.rules
+ln -sf ../xenomai.rules /etc/udev/rules.d/xenomai.rules
+;;
+
+abort-upgrade|abort-remove|abort-deconfigure)
+;;
+
+*)
+echo postinst called with unknown argument \`$1' 2
+exit 1
+;;
+esac
#DEBHELPER#
diff -uNrp xenomai-2.5.1.orig/debian/libxenomai1.xenomai.init
xenomai-2.5.1/debian/libxenomai1.xenomai.init
--- xenomai-2.5.1.orig/debian/libxenomai1.xenomai.init 1970-01-01
01:00:00.0 +0100
+++ xenomai-2.5.1/debian/libxenomai1.xenomai.init 2010-02-26
01:48:28.0 +0100
@@ -0,0 +1,36 @@
+#!/bin/sh -e
+### BEGIN INIT INFO
+# Provides: xenomai
+# Required-Start:mountkernfs
+# Required-Stop:
+# Default-Start: S
+# Default-Stop:
+# Short-Description: Set xeno_nucleus group
+### END INIT INFO
+
+GROUP=xenomai
+INITNAME=/etc/init.d/xenomai
+FILENAME=/sys/module/xeno_nucleus/parameters/xenomai_gid
+GID=$(getent group $GROUP | cut -d: -f3)
+
+test -e $FILENAME || exit 0
+test -n $GID || exit 0
+
+case $1 in
+ start)
+echo $GID $FILENAME
+;;
+ stop)
+echo -1 $FILENAME
+;;
+ restart|force-reload)
+$0 start
+;;
+ *)
+echo Usage: $INITNAME {start|stop|restart|force-reload}
+exit 1
+;;
+esac
+
+exit 0
+
diff -uNrp xenomai-2.5.1.orig/debian/rules xenomai-2.5.1/debian/rules
--- xenomai-2.5.1.orig/debian/rules 2010-02-26 01:01:07.0 +0100
+++ xenomai-2.5.1/debian/rules 2010-02-26 01:17:19.0 +0100
@@ -100,6 +100,7 @@ install: build
for f in $(CURDIR)/ksrc/nucleus/udev/*.rules ; do \
cat $$f $(CURDIR)/debian/libxenomai1/etc/udev/xenomai.rules ; \
done
+ install -m 644 debian/libxenomai1.modprobe
$(CURDIR)/debian/libxenomai1/etc/modprobe.d/xenomai
# remove empty directory
rm -rf $(CURDIR)/debian/xenomai-doc/usr/share/doc/xenomai-doc/ps
cp debian/libxenomai1.lintian
$(CURDIR)/debian/libxenomai1/usr/share/lintian/overrides/libxenomai1
@@ -132,6 +133,7 @@ binary-indep: build install
binary-arch: build install
dh_testdir -s
dh_testroot -s
+ dh_installinit -s --name=xenomai
dh_installman -s
dh_installdocs -s -A CREDITS README.INSTALL TROUBLESHOOTING
dh_link -s
signature.asc
Description: OpenPGP digital signature
Re: [Xenomai-core] Xenomai in Debian
Am 26.02.2010 14:28, schrieb Philippe Gerum: On Fri, 2010-02-26 at 14:13 +0100, Stefan Kisdaroczi wrote: Am 24.02.2010 14:13, schrieb Philippe Gerum: On Wed, 2010-02-24 at 14:11 +0100, Philippe Gerum wrote: On Wed, 2010-02-24 at 14:06 +0100, Stefan Kisdaroczi wrote: Hi Philippe, Am 23.02.2010 18:46, schrieb Philippe Gerum: On Tue, 2010-02-23 at 17:52 +0100, Stefan Kisdaroczi wrote: Hi, Am 14.02.2010 10:38, schrieb Philippe Gerum: snip In the future, maybe we could simply provide a wrapper script accepting sub-commands, such as xeno latency, xeno sigtest etc, to be put into /usr/bin by distros, which would hide the actual location of those binaries? In any case, thanks for your work so far. We probably need to discuss the packaging issues on this list, so that we get both consistency and usability in the future. Gilles and Roland, if this is fine with you, I'll handle the liaison role with upstream packagers, so please CC me explicitly on those mails. We'll sort out this issue, it doesn't look that bad anyway. Roland added a xeno wrapper to the debian.org xenomai package 2.5.1-3. I synced now the debian/ directories from debian.org and xenomai.org: - For debian.org I sent patches to the Debian bugtracker [1] [2]. Another patch for dpkg-cross support [3] I sent to Roland privately. - For xenomai.org I attached patches to this mail (against -2.5.git). If both parties apply the patches the debian directories are in sync, except some minor differences in the debian/control file, see patch do-not-commit-please.patch. I would like to keep these changes out so that the xenomai.org packages are compatible with Debian 5.0 Lenny. The debian.org packages are for Debian 6.0 Squeeze. Merged into my queue (except the last one as mentioned). This will be pushed upstream to Gilles for 2.5.2. Thanks. I took a look at your branch for-upstream. Your commit scripts: add wrapper script to run standard Xenomai commands 6e0574791f48cbf8b3421a68c5789254e7d084b7 adds the same wrapper as my patch 0005-debian-wrapper-script-usr-bin-xeno-to-call-executa.patch debian: wrapper script /usr/bin/xeno to call executables in /usr/lib/xenomai/ fbe86cc50d3a65cd23e93d43adba4ed369fe70b1 Please revert the commit of my patch, we need another fix for debian/rules for your wrapper. Ok, I thought your patch set was based on my tree, so I did not check thoroughly. I did not send any pull request to Gilles, so no harm done. How do I call configure to install the wrapper in /usr/bin and the programs like latency, switchtest etc. to /usr/lib/xenomai ? We need some fixage in scripts/wrappers/Makefile.am to do that. I'll prepare this asap. scripts/Makefile.am... Hi Philippe, I just tried the --with-testdir switch. It worked, but i'm not really sure if this is the right track. Roland's packages install all binaries to /usr/lib/xenomai, except xeno and xeno-config. You state in your commit message more or less the same goal: At some point, all remaining executables or scripts left under $prefix/bin should match xeno*, to further reduce the odds of causing name collisions. Using --with-testdir all tests (latency,switchtest,...) are now in /usr/lib/xenomai. To install the utils (rtcansend,insn_write,insn_write,cmd_read,...) to the same directory using --with-testdir sounds not obviously. You could add a second switch --with-utildir, but a second dir will not work for the xeno-wrapper-script. CAN and other utilities should definitely remain in $bindir. The fact that they are not prefixed by xeno* is another thing; CAN utilities are already prefixed, maybe Analogy ones should be named in a bit less generic way, although they are not raising any conflict today. I wrote that what's under $bindir should match xeno* when a risk of collision exists, but there is no point in enforcing a stricter rule at this point. In any case, I don't want to enforce a never-in-bindir rule for all Xenomai binaries, we can still pick their names in a way that avoids obvious issues. The real problem was about tests, for which using rather generic names made sense. This is what that patch is for. ok, got the goal now, thanks for the explanation. But xeno.in needs a fix to use @XENO_TEST_DIR@, no? I think something like using --bindir=/usr/lib/xenomai and --wrapperdir=/usr/bin is probably better, as there are less exceptions. For the test I patched xeno.in: exec @XENO_TEST_DIR@/$@ Stefan Stefan Thanks kisda [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571099 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571104 [3] http://git.xenomai.org/?p=xenomai-2.5.git;a=commitdiff;h=5bcd18f714f4cbeaaac0cc4a08e6c9f375aa3b77 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 in Debian
Am 24.02.2010 14:06, schrieb Stefan Kisdaroczi: Hi Philippe, Am 23.02.2010 18:46, schrieb Philippe Gerum: On Tue, 2010-02-23 at 17:52 +0100, Stefan Kisdaroczi wrote: Hi, Am 14.02.2010 10:38, schrieb Philippe Gerum: snip In the future, maybe we could simply provide a wrapper script accepting sub-commands, such as xeno latency, xeno sigtest etc, to be put into /usr/bin by distros, which would hide the actual location of those binaries? In any case, thanks for your work so far. We probably need to discuss the packaging issues on this list, so that we get both consistency and usability in the future. Gilles and Roland, if this is fine with you, I'll handle the liaison role with upstream packagers, so please CC me explicitly on those mails. We'll sort out this issue, it doesn't look that bad anyway. Roland added a xeno wrapper to the debian.org xenomai package 2.5.1-3. I synced now the debian/ directories from debian.org and xenomai.org: - For debian.org I sent patches to the Debian bugtracker [1] [2]. Another patch for dpkg-cross support [3] I sent to Roland privately. - For xenomai.org I attached patches to this mail (against -2.5.git). If both parties apply the patches the debian directories are in sync, except some minor differences in the debian/control file, see patch do-not-commit-please.patch. I would like to keep these changes out so that the xenomai.org packages are compatible with Debian 5.0 Lenny. The debian.org packages are for Debian 6.0 Squeeze. Merged into my queue (except the last one as mentioned). This will be pushed upstream to Gilles for 2.5.2. Thanks. I took a look at your branch for-upstream. Your commit scripts: add wrapper script to run standard Xenomai commands 6e0574791f48cbf8b3421a68c5789254e7d084b7 adds the same wrapper as my patch 0005-debian-wrapper-script-usr-bin-xeno-to-call-executa.patch debian: wrapper script /usr/bin/xeno to call executables in /usr/lib/xenomai/ fbe86cc50d3a65cd23e93d43adba4ed369fe70b1 Please revert the commit of my patch, we need another fix for debian/rules for your wrapper. Thanks for reverting. Roland has uploaded 2.5.1-4 yesterday. Attached a patch to stay in sync. Based on your for-upstream branch this time. kisda How do I call configure to install the wrapper in /usr/bin and the programs like latency, switchtest etc. to /usr/lib/xenomai ? Stefan Thanks kisda [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571099 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571104 [3] http://git.xenomai.org/?p=xenomai-2.5.git;a=commitdiff;h=5bcd18f714f4cbeaaac0cc4a08e6c9f375aa3b77 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core From f6b7a0115f3f785f08f8d085e66c8bf8d7057f88 Mon Sep 17 00:00:00 2001 From: Stefan Kisdaroczi ki...@hispeed.ch Date: Thu, 25 Feb 2010 13:27:31 +0100 Subject: [PATCH] debian: sync 2.5.1-4 from debian.org --- debian/changelog|9 + debian/libxenomai1.dirs |2 +- 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/debian/changelog b/debian/changelog index 45736a4..6d2d3cf 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +xenomai (2.5.1-4) unstable; urgency=low + + * Added patches by Stefan Kisdaroczi ki...@hispeed.ch: +- debian/copyright: Typo and email address (Closes: #571099) +- debian/control: ia64 support removed (Closes: #571104) +- debian/rules: Added dpkg-cross support + + -- Roland Stigge sti...@antcom.de Wed, 24 Feb 2010 22:20:10 +0100 + xenomai (2.5.1-3) unstable; urgency=low * xenomai-runtime: Replaced xenomai- prefixed executables with diff --git a/debian/libxenomai1.dirs b/debian/libxenomai1.dirs index d5bb34f..1737ea1 100644 --- a/debian/libxenomai1.dirs +++ b/debian/libxenomai1.dirs @@ -1,2 +1,2 @@ -etc/udev +etc/udev/rules.d usr/share/lintian/overrides -- 1.5.6.5 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 in Debian
Am 25.02.2010 14:49, schrieb Gilles Chanteperdrix: Stefan Kisdaroczi wrote: Hi, Am 14.02.2010 10:38, schrieb Philippe Gerum: snip In any case, thanks for your work so far. We probably need to discuss the packaging issues on this list, so that we get both consistency and usability in the future. Gilles and Roland, if this is fine with you, I'll handle the liaison role with upstream packagers, so please CC me explicitly on those mails. We'll sort out this issue, it doesn't look that bad anyway. udev/xenomai.rules sets the group for realtime devices to xenomai. Patch attached to create the group xenomai on installation. Additionally, it would be nice to set xeno_nucleus.xenomai_gid to group xenomai too. Is this possible with a udev rule ? Well, no, xeno_nucleus.xenomai_gid is a kernel parameter, so it is boot loader stuff. However, if xeno_nucleus is compiled as a module, you can add parameters in /etc/modprobe.d. Well, that would have been the place to do it some time ago. I may not be completely up-to-date. Hi Gilles, can a init.d script with echo gid /sys/module/xeno_nucleus/parameters/xenomai_gid work in module and builtin case ? regards kisda ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core 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 in Debian
Am 25.02.2010 15:29, schrieb Stefan Kisdaroczi:
Am 25.02.2010 14:59, schrieb Stefan Kisdaroczi:
Am 25.02.2010 14:49, schrieb Gilles Chanteperdrix:
Stefan Kisdaroczi wrote:
Hi,
Am 14.02.2010 10:38, schrieb Philippe Gerum:
snip
In any case, thanks for your work so far. We probably need to discuss
the packaging issues on this list, so that we get both consistency and
usability in the future.
Gilles and Roland, if this is fine with you, I'll handle the liaison
role with upstream packagers, so please CC me explicitly on those mails.
We'll sort out this issue, it doesn't look that bad anyway.
udev/xenomai.rules sets the group for realtime devices to xenomai.
Patch attached to create the group xenomai on installation.
Additionally, it would be nice to set xeno_nucleus.xenomai_gid to
group xenomai too. Is this possible with a udev rule ?
Well, no, xeno_nucleus.xenomai_gid is a kernel parameter, so it is boot
loader stuff. However, if xeno_nucleus is compiled as a module, you can
add parameters in /etc/modprobe.d. Well, that would have been the place
to do it some time ago. I may not be completely up-to-date.
Hi Gilles,
can a init.d script with
echo gid /sys/module/xeno_nucleus/parameters/xenomai_gid
work in module and builtin case ?
it seems that init.d will work for the builtin case and modprobe.d for the
module case. So adding both should work in all cases :-)
I'll give it a try ...
Attached a patch that adds a init-script /etc/init.d/xenomai to the package
libxenomai1.
If group xenomai and the file /sys/module/xeno_nucleus/parameters/xenomai_gid
are found,
xenomai_gid is set on startup.
Now looking at modprobe.d ...
regards
kisda
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
diff -uNrp xenomai-2.5.1/debian/libxenomai1.xenomai.init
xenomai-2.5.1.new/debian/libxenomai1.xenomai.init
--- xenomai-2.5.1/debian/libxenomai1.xenomai.init 1970-01-01
01:00:00.0 +0100
+++ xenomai-2.5.1.new/debian/libxenomai1.xenomai.init 2010-02-25
17:13:51.0 +0100
@@ -0,0 +1,37 @@
+#!/bin/sh -e
+### BEGIN INIT INFO
+# Provides: xenomai
+# Required-Start:mountkernfs
+# Required-Stop:
+# Default-Start: S
+# Default-Stop:
+# Short-Description: Set xeno_nucleus group
+### END INIT INFO
+
+GROUP=xenomai
+INITNAME=/etc/init.d/xenomai
+FILENAME=/sys/module/xeno_nucleus/parameters/xenomai_gid
+GID=$(getent group $GROUP | cut -d: -f3)
+
+test -e $FILENAME || exit 0
+test -n $GID || exit 0
+
+case $1 in
+ start)
+echo $GID $FILENAME
+;;
+ stop)
+echo -1 $FILENAME
+;;
+ restart|force-reload)
+$0 stop
+$0 start
+;;
+ *)
+echo Usage: $INITNAME {start|stop|restart|force-reload}
+exit 1
+;;
+esac
+
+exit 0
+
diff -uNrp xenomai-2.5.1/debian/rules xenomai-2.5.1.new/debian/rules
--- xenomai-2.5.1/debian/rules 2010-02-25 16:56:05.0 +0100
+++ xenomai-2.5.1.new/debian/rules 2010-02-25 17:33:20.0 +0100
@@ -132,6 +132,7 @@ binary-indep: build install
binary-arch: build install
dh_testdir -s
dh_testroot -s
+ dh_installinit -s --name=xenomai
dh_installman -s
dh_installdocs -s -A CREDITS README.INSTALL TROUBLESHOOTING
dh_link -s
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 in Debian
Hi, Am 14.02.2010 10:38, schrieb Philippe Gerum: snip In the future, maybe we could simply provide a wrapper script accepting sub-commands, such as xeno latency, xeno sigtest etc, to be put into /usr/bin by distros, which would hide the actual location of those binaries? In any case, thanks for your work so far. We probably need to discuss the packaging issues on this list, so that we get both consistency and usability in the future. Gilles and Roland, if this is fine with you, I'll handle the liaison role with upstream packagers, so please CC me explicitly on those mails. We'll sort out this issue, it doesn't look that bad anyway. Roland added a xeno wrapper to the debian.org xenomai package 2.5.1-3. I synced now the debian/ directories from debian.org and xenomai.org: - For debian.org I sent patches to the Debian bugtracker [1] [2]. Another patch for dpkg-cross support [3] I sent to Roland privately. - For xenomai.org I attached patches to this mail (against -2.5.git). If both parties apply the patches the debian directories are in sync, except some minor differences in the debian/control file, see patch do-not-commit-please.patch. I would like to keep these changes out so that the xenomai.org packages are compatible with Debian 5.0 Lenny. The debian.org packages are for Debian 6.0 Squeeze. Thanks kisda [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571099 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571104 [3] http://git.xenomai.org/?p=xenomai-2.5.git;a=commitdiff;h=5bcd18f714f4cbeaaac0cc4a08e6c9f375aa3b77 From f8bfbe147654f9eb240b0e94d774185940444b8d Mon Sep 17 00:00:00 2001 From: Stefan Kisdaroczi ki...@hispeed.ch Date: Tue, 23 Feb 2010 13:06:52 +0100 Subject: [PATCH] debian: copyright: fix typo and add project url --- debian/copyright |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/debian/copyright b/debian/copyright index 683e276..b3980df 100644 --- a/debian/copyright +++ b/debian/copyright @@ -3,6 +3,8 @@ On: Sat Mar 3 12:00 GMT 2007 The primary author of the upstream package is Philippe Gerum. +It was downloaded from http://www.xenomai.org/ + Copyright (C) 2001,2002,2003,2004,2005,2006,2007,2008 Philippe Gerum r...@xenomai.org. Copyright (C) 2005 Dmitry Adamushko dmitry.adamus...@gmail.com Copyright (C) 2001,2003,2004,2005,2006,2008 Gilles Chanteperdrix gilles.chanteperd...@xenomai.org @@ -11,7 +13,7 @@ Copyright (C) 2006 Wolfgang Grandegger w...@grandegger.com License: -Xenmai is licensed under GPL version 2, the user space libraries are LGPL +Xenomai is licensed under GPL version 2, the user space libraries are LGPL version 2.1. On Debian systems, the complete texts of the GNU General Public License v2 and the GNU Lesser General Public License v2 can be found in the file -- 1.5.6.5 From d3827b9eda17d8332748767b2ae5282f5fcb283d Mon Sep 17 00:00:00 2001 From: Stefan Kisdaroczi ki...@hispeed.ch Date: Tue, 23 Feb 2010 16:21:23 +0100 Subject: [PATCH] debian: libxenomai1: sync from debian.org --- debian/libxenomai1.lintian |2 +- debian/libxenomai1.postinst |2 +- debian/libxenomai1.postrm |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/debian/libxenomai1.lintian b/debian/libxenomai1.lintian index 42a4149..0f6a514 100644 --- a/debian/libxenomai1.lintian +++ b/debian/libxenomai1.lintian @@ -1,2 +1,2 @@ # no contained shared library names refer to xenomai, therefore own name -libxenomai1: package-name-doesnt-match-sonames libnative1 libpsos0 libpthread-rt1 librtai0 librtdk0 librtdm1 libuitron0 libvrtx0 libvxworks1 +libxenomai1: package-name-doesnt-match-sonames libanalogy1 libnative3 libpsos0 libpthread-rt1 librtai0 librtdk0 librtdm1 libuitron0 libvrtx0 libvxworks1 diff --git a/debian/libxenomai1.postinst b/debian/libxenomai1.postinst index dfdaa46..8afc6fc 100644 --- a/debian/libxenomai1.postinst +++ b/debian/libxenomai1.postinst @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/sh -e rm -f /etc/udev/rules.d/xenomai.rules ln -sf ../xenomai.rules /etc/udev/rules.d/xenomai.rules diff --git a/debian/libxenomai1.postrm b/debian/libxenomai1.postrm index a269ef5..3559eb5 100644 --- a/debian/libxenomai1.postrm +++ b/debian/libxenomai1.postrm @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/sh -e case $1 in purge | remove) -- 1.5.6.5 From c05d1fbfdd9360785b82be3d4437fe2b0e39b647 Mon Sep 17 00:00:00 2001 From: Stefan Kisdaroczi ki...@hispeed.ch Date: Tue, 23 Feb 2010 16:28:39 +0100 Subject: [PATCH] debian: linux-patch-xenomai.README.Debian: sync from debian.org --- debian/linux-patch-xenomai.README.Debian |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/debian/linux-patch-xenomai.README.Debian b/debian/linux-patch-xenomai.README.Debian index a6aaa6b..3304bf5 100644 --- a/debian/linux-patch-xenomai.README.Debian +++ b/debian/linux-patch-xenomai.README.Debian @@ -4,12 +4,14 @@ Xenomai kernel patches in Debian With this package, you can patch and build kernels
Re: [Xenomai-core] Yet another ((weak)) bug
Am 12.02.2010 17:22, schrieb Jan Kiszka: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Gilles Chanteperdrix wrote: Jan Kiszka wrote: Hi Gilles, this one requires some fixing too: xeno_sem_heap is marked weak. xeno_init_sem_heaps is called once per initialized skin. It unmaps any existing heap and creates a new one. That's already fragile during constructor run, but it's lethal during process runtime, ie. when using dlopen. I think the solution is to handle forks separately and only remap in that case. Digging in this direction now. BTW, what triggers the re-run of xeno_init_sem_heaps after a fork so far? It must be done for the child process to get a private heap different from the parent process. I would guess it is handled by pthread_atfork. Ah, only the POSIX skin does that. However, sem-heaps must not be POSIX-only. OK, patch in the make. Ok. I am thinking more and more that you are right about making libxeno_common a standalone library. Only the name stinks, we should find a better one. libxnskin or so? Jan libxenomai ? Stefan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem running klatency test
Shashank Bhatia schrieb:
[...]
open(/proc/xenomai/registry/native/pipes/klat_pipe): No such file or
directory
modprobe klat_mod or try the -P option?
the module ist called xeno_klat. patch attached.
diff --git a/src/testsuite/klatency/klatency.c
b/src/testsuite/klatency/klatency.c
index a22cd59..c419402 100644
--- a/src/testsuite/klatency/klatency.c
+++ b/src/testsuite/klatency/klatency.c
@@ -187,7 +187,7 @@ int main(int argc, char **argv)
if (benchdev == -1) {
perror(open(/proc/xenomai/registry/native/pipes/klat_pipe));
fprintf(stderr,
- modprobe klat_mod or try the -P option?\n);
+ modprobe xeno_klat or try the -P option?\n);
exit(EXIT_FAILURE);
}
} else {
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problem running klatency test
Hi, Shashank Bhatia schrieb: Dear All, I could manage to compile my patched kernel on ubuntu using the following guide : https://wiki.ubuntu.com/KernelTeam/GitKernelBuild Now when i installed Xenomai, i could run the latency tests, but when i tried to run the kernel space latency test, i found the following error. r...@shashank-desktop:/usr/share/xenomai/testsuite/klatency# ./run * * * Type ^C to stop this application. * * open(/proc/xenomai/registry/native/pipes/klat_pipe): No such file or directory modprobe klat_mod or try the -P option? 1) go to your xeno-patched kernel tree 2) make menuconfig 3) navigate to Real-time sub-system --- Drivers --- Testing Drivers 4) enable 'Timer benchmark driver' 5) a new options pops up: 'Kernel-only latency measurement module' 6) enable this option 7) rebuild kernel install kernel reboot 8) try again, if you enabled it as a module (M) and not built-in (*) use modprobe to load to module kisda The dmesg | grep Xenomai gave the following output: [4.353912] I-pipe: Domain Xenomai registered. [4.353949] Xenomai: hal/i386 started. [4.354530] Xenomai: real-time nucleus v2.4.8 (Lords Of Karma) loaded. [4.354612] Xenomai: SMI-enabled chipset found [4.354623] Xenomai: SMI workaround enabled [4.354647] Xenomai: starting native API services. [4.354650] Xenomai: starting POSIX services. [4.354693] Xenomai: starting RTDM services. Thanks in advance - Hi-Tech Gears Limited, Gurgaon, India ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] xenomai homepage: missing description
hi, suggestion for www.xenomai.org, page 'home': as its the first page displayed, there should be a small description about xenomai. You can take the first paragraph at gna [1] and add the supported archs and mention the GPL: 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 environment. Architectures: Linux 2.4: x86,ppc32 Linux 2.6: arm,blackfin,ia64,ppc32,ppc64,x86 License: GNU General Public License V2 wow... what a arch list... is this true ? Is there a way to make the cloud a bit smaller and put something like the above there ? kisda [1] https://gna.org/projects/xenomai pgp8O6RpgZT7z.pgp Description: PGP signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] rt_heap reminder
Hi all,
as a reminder (userspace, native skin, shared heap) [1]:
API documentation: If the heap is shared, this value can be either zero, or
the same value given to rt_heap_create().
This is not true. As the heapsize gets altered in rt_heap_create for page size
alignment, the following call to rt_heap_alloc with the same value will fail.
Ex:
rt_heap_create( ..., ..., 1, ... )
rt_heap_alloc( ..., 1, ..., ) - This call fails
I suggest only accepting zero as a valid size for shared heaps.
about attached patch:
1) not tested
2) there are possible better names than H_ALL
3) the comments could be in a better english
4) i hope you get the idea
thx
kisda
[1] https://mail.gna.org/public/xenomai-core/2006-01/msg00177.html
Index: include/native/heap.h
===
--- include/native/heap.h (Revision 465)
+++ include/native/heap.h (Arbeitskopie)
@@ -32,6 +32,9 @@
#define H_DMA0x100 /* Use memory suitable for DMA. */
#define H_SHARED 0x200 /* Use mappable shared memory. */
+/* Operation flags. */
+#define H_ALL0x0 /* Entire heap space. */
+
typedef struct rt_heap_info {
int nwaiters; /* ! Number of pending tasks. */
Index: ksrc/skins/native/heap.c
===
--- ksrc/skins/native/heap.c (Revision 465)
+++ ksrc/skins/native/heap.c (Arbeitskopie)
@@ -410,10 +410,9 @@
* from.
*
* @param size The requested size in bytes of the block. If the heap
- * is shared, this value can be either zero, or the same value given
- * to rt_heap_create(). In any case, the same block covering the
- * entire heap space will always be returned to all callers of this
- * service.
+ * is shared, H_ALL should be passed, as always the same block
+ * covering the entire heap space will be returned to all callers of
+ * this service.
*
* @param timeout The number of clock ticks to wait for a block of
* sufficient size to be available from a local heap (see
@@ -432,8 +431,7 @@
* @return 0 is returned upon success. Otherwise:
*
* - -EINVAL is returned if @a heap is not a heap descriptor, or @a
- * heap is shared (i.e. H_SHARED mode) and @a size is non-zero but
- * does not match the actual heap size passed to rt_heap_create().
+ * heap is shared (i.e. H_SHARED mode) and @a size is not H_ALL.
*
* - -EIDRM is returned if @a heap is a deleted heap descriptor.
*
@@ -503,12 +501,7 @@
if (!block)
{
- /* It's ok to pass zero for size here, since the requested
- size is implicitely the whole heap space; but if
- non-zero is given, it must match the actual heap
- size. */
-
- if (size 0 size != xnheap_size(heap-heap_base))
+ if (size != H_ALL)
{
err = -EINVAL;
goto unlock_and_exit;
pgpsDlebpJPHk.pgp
Description: PGP signature
[Xenomai-core] rt_heap in userspace, heapsize
Hi, I made a small test with rt_heap_ in userspace, i think I understood the actual limitations of the userspace support. I used 1 as heapsize. Xenomai 2.1-RC2/x86. This should alloc the entire heap, according to the API documentation: rt_heap_create( ..., ..., 1, ... ) rt_heap_alloc( ..., 1, ..., ) - This call fails, but it should work Using heapsize 0 it works: rt_heap_create( ..., ..., 1, ... ) rt_heap_alloc( ..., 0, ..., ) rt_heap_inquire shows a heapsize of 12228 (IIRC). So, this would probably work (untested): rt_heap_create( ..., ..., 1, ... ) rt_heap_alloc( ..., 12228, ..., ) The 2228 bytes difference seems to be the space needed for the heap control structures. I think the following should be fixed: 1) rt_create_alloc should alter the heapsize the same as rt_heap_create does 2) rt_heap_inquire should return the _real_ heapsize thx kisda signature.asc Description: OpenPGP digital signature
Re: [Xenomai-core] rt_heap in userspace, heapsize [patch]
Hi again,
I looked at the sources now...
Am Tuesday 17 January 2006 14:57 schrieb Stefan Kisdaroczi:
Hi,
I made a small test with rt_heap_ in userspace,
i think I understood the actual limitations of the userspace support.
I used 1 as heapsize. Xenomai 2.1-RC2/x86.
This should alloc the entire heap, according to the API documentation:
rt_heap_create( ..., ..., 1, ... )
rt_heap_alloc( ..., 1, ..., ) - This call fails, but it should
work
API documentation: If the heap is shared, this value can be either zero, or
the same value given to rt_heap_create().
Looking at the code, calculating the right value can be tricky and would
depend on xeno-internals. rt_heap_inquire would be another way to get it.
Only accepting 0 would be less confusing. See (untested) patch as as
suggestion.
Using heapsize 0 it works:
rt_heap_create( ..., ..., 1, ... )
rt_heap_alloc( ..., 0, ..., )
rt_heap_inquire shows a heapsize of 12228 (IIRC).
So, this would probably work (untested):
rt_heap_create( ..., ..., 1, ... )
rt_heap_alloc( ..., 12228, ..., )
The 2228 bytes difference seems to be the space needed for the heap control
structures.
I think the following should be fixed:
1) rt_create_alloc should alter the heapsize the same as rt_heap_create
does
Makes no sense, after looking at the code.
2) rt_heap_inquire should return the _real_ heapsize
The real heap space can be bigger than the requested, so this can happen.
thx again
kisda
Index: include/native/heap.h
===
--- include/native/heap.h (Revision 465)
+++ include/native/heap.h (Arbeitskopie)
@@ -32,6 +32,9 @@
#define H_DMA0x100 /* Use memory suitable for DMA. */
#define H_SHARED 0x200 /* Use mappable shared memory. */
+/* Operation flags. */
+#define H_ALL0x0 /* Entire heap space. */
+
typedef struct rt_heap_info {
int nwaiters; /* ! Number of pending tasks. */
Index: ksrc/skins/native/heap.c
===
--- ksrc/skins/native/heap.c (Revision 465)
+++ ksrc/skins/native/heap.c (Arbeitskopie)
@@ -410,10 +410,9 @@
* from.
*
* @param size The requested size in bytes of the block. If the heap
- * is shared, this value can be either zero, or the same value given
- * to rt_heap_create(). In any case, the same block covering the
- * entire heap space will always be returned to all callers of this
- * service.
+ * is shared, H_ALL should be passed, as always the same block
+ * covering the entire heap space will be returned to all callers of
+ * this service.
*
* @param timeout The number of clock ticks to wait for a block of
* sufficient size to be available from a local heap (see
@@ -432,8 +431,7 @@
* @return 0 is returned upon success. Otherwise:
*
* - -EINVAL is returned if @a heap is not a heap descriptor, or @a
- * heap is shared (i.e. H_SHARED mode) and @a size is non-zero but
- * does not match the actual heap size passed to rt_heap_create().
+ * heap is shared (i.e. H_SHARED mode) and @a size is not H_ALL.
*
* - -EIDRM is returned if @a heap is a deleted heap descriptor.
*
@@ -503,12 +501,7 @@
if (!block)
{
- /* It's ok to pass zero for size here, since the requested
- size is implicitely the whole heap space; but if
- non-zero is given, it must match the actual heap
- size. */
-
- if (size 0 size != xnheap_size(heap-heap_base))
+ if (size != H_ALL)
{
err = -EINVAL;
goto unlock_and_exit;
pgplgPWGQzm4P.pgp
Description: PGP signature
[Xenomai-core] rt_task_spawn with NULL name and pascal linking
Hi, I needed a lot coffee and tobacco resources to find out that rt_task_spawn with NULL name will not work in userspace. The call failed with -3 (ESRCH?). This error seems not documented the xenomai api documention. Using rt_task_create and rt_task_start it was rt_task_start that failed. I think this is related to Jans statement below. As rt_task_spawn is a inline function and a combination of create/start, this can be confusing. I.e. rt_task_shadow works with NULL name and rt_task_spawn dont. At this point I should mention that im testing my pascal-translations of the xenomai native and rtdm headers, but i dont see that the problem should be related to it, I searched the problem a long time i this part ;-) Some questions: Im still using Xenomai 2.0.1, is this the problem ? Shouldnt this be documented better ? Would it work if rt_task_spawn is a skincall? pascal-related: Is there a way to export the c-inline functions also in the libs, so that the complete api is exported ? rt_task_spawn and some rt_*_unbind funtions are inlined. Its not a problem to reprogram these in pascal, but for maintenance reasons it would be nice if i could link against these functions. greetings kisda Am Donnerstag, 8. Dezember 2005 20.40 schrieb Jan Kiszka: Hi again, some questions just came up for me: 1. Is it intended that tasks created with NULL name in userspace are not accessible even to the creator? I.e. don't they have to register anonymously in that case like semaphores e.g. do? pgpw6ySLonvmR.pgp Description: PGP signature
[Xenomai-core] src/skins/*/COPYING consistency
hi, license detail: in every src/skins/*/ directory containing source is a LGPL COPYING file, except in rtdm. For consistency there should be also one. Or only one file src/skins/COPYING ? thx kisda pgpuQPXItL6DJ.pgp Description: PGP signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCHES] various fixes
Hi Jan, Am Montag, 2. Januar 2006 14.36 schrieb Jan Kiszka: * rtdm-license.patch - add missing COPYING files to RTDM skin and lib (or go for just a single file for ksrc/skins and src/skins if this is applicable) The COPYING file in your patch contains the GPL license. Should'nt it be the LGPL license ? I mean, its your choice :-), but all other skins are LGPL and in the headers of the rtdm/*.c-files is also the LGPL license. greetings kisda pgpOoYiYbq9c9.pgp Description: PGP signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] src/skins/*/COPYING consistency
hi, license detail: in every src/skins/*/ directory containing source is a LGPL COPYING file, except in rtdm. For consistency there should be also one. Or only one file src/skins/COPYING ? thx kisda pgp2HGvCfie1Q.pgp Description: PGP signature
Re: [Xenomai-core] [PATCHES] various fixes
Hi Jan, Am Montag, 2. Januar 2006 14.36 schrieb Jan Kiszka: * rtdm-license.patch - add missing COPYING files to RTDM skin and lib (or go for just a single file for ksrc/skins and src/skins if this is applicable) The COPYING file in your patch contains the GPL license. Should'nt it be the LGPL license ? I mean, its your choice :-), but all other skins are LGPL and in the headers of the rtdm/*.c-files is also the LGPL license. greetings kisda pgpfM6U7GMYk9.pgp Description: PGP signature
[Xenomai-core] autostart timer, rt_timer_start/stop
Hi, cant the timer be started by default ? The current state (2.0.1) seems to lead to the following scenario: 1) Every app calls rt_timer_start() 2) If you call rt_timer_stop you can hurt other rt-apps, so dont call it 3) As some apps dont stop the timer, check in 1) if its already running I think most apps do not care in which mode the timer is running if it is already, and just go on, of course you can stop and restart the timer if its a wrong state, but you do not know if you hurt others. Now, as i read in the other thread that the periodic timer support isnt configured by default, why not start the oneshot timer automatic ? Like this, a 'normal' app doesnt need to fiddle with the timer and an app that really cares can still call rt_timer_inquire,_stop,_start. kisda signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] autostart timer, rt_timer_start/stop
Hi, cant the timer be started by default ? The current state (2.0.1) seems to lead to the following scenario: 1) Every app calls rt_timer_start() 2) If you call rt_timer_stop you can hurt other rt-apps, so dont call it 3) As some apps dont stop the timer, check in 1) if its already running I think most apps do not care in which mode the timer is running if it is already, and just go on, of course you can stop and restart the timer if its a wrong state, but you do not know if you hurt others. Now, as i read in the other thread that the periodic timer support isnt configured by default, why not start the oneshot timer automatic ? Like this, a 'normal' app doesnt need to fiddle with the timer and an app that really cares can still call rt_timer_inquire,_stop,_start. kisda signature.asc Description: OpenPGP digital signature
