Re: [Xenomai-core] System-V initialization script
Romain Lenglet wrote:
Hi,
Here is a patch that adds a System-V init script to the
distribution. This script creates/deletes the devices in /dev
and sets the latency through /proc/xenomai/latency.
Please re-run automake before committing (if committing).
Ok, queued for 2.1.1. Thanks.
Is there anything more it should do? For instance, is there a way
to start the timer through one of the /proc/xenomai/*
pseudo-files?
v2.1 starts the timer as part of the nucleus startup procedure, so it should not
be needed to do so on boot. This said, providing a write side to
/proc/xenomai/timer so that we could change the setup on-the-fly looks like a good
idea.
--- xenomai/ChangeLog 2006-03-06 12:51:03.624869000 +0900
+++ xenomai-new/ChangeLog 2006-03-06 17:03:52.806802824 +0900
@@ -1,3 +1,9 @@
+2006-03-06 Romain Lenglet [EMAIL PROTECTED]
+
+ * scripts/etc/init.d/xenomai, scripts/etc/default/xenomai,
+ scripts/etc/README scripts/Makefile.am: Add a System-V-like init script
+ for creating devices and setting the scheduling latency at boot time.
+
2006-03-05 Philippe Gerum [EMAIL PROTECTED]
* ksrc/skins/vxworks/taskLib.c (taskPrioritySet): Return ERROR
--- xenomai/scripts/Makefile.am 2006-02-27 09:51:18.379979776 +0900
+++ xenomai-new/scripts/Makefile.am 2006-03-06 17:03:27.412663320 +0900
@@ -8,4 +8,5 @@
EXTRA_DIST = bootstrap prepare-kernel.sh xeno-info \
Kconfig.frag Modules.frag defconfig.frag \
+ etc/init.d/xenomai etc/default/xenomai etc/README \
$(wildcard postinstall.sh)
diff -Naurd xenomai/scripts/etc/default/xenomai
xenomai-new/scripts/etc/default/xenomai
--- xenomai/scripts/etc/default/xenomai 1970-01-01 09:00:00.0 +0900
+++ xenomai-new/scripts/etc/default/xenomai 2006-03-06 16:40:30.264021736
+0900
@@ -0,0 +1,6 @@
+# The group that owns the Xenomai devices in /dev/.
+GROUP=root
+# The access mode to the Xenomai devices in /dev/.
+MODE=0770
+# The real-time scheduling latency.
+LATENCY=0
diff -Naurd xenomai/scripts/etc/init.d/xenomai
xenomai-new/scripts/etc/init.d/xenomai
--- xenomai/scripts/etc/init.d/xenomai 1970-01-01 09:00:00.0 +0900
+++ xenomai-new/scripts/etc/init.d/xenomai 2006-03-06 17:12:24.006088720
+0900
@@ -0,0 +1,98 @@
+#! /bin/sh
+#
+# xenomai Xenomai Real-time framework for Linux.
+# This script sets up devices in /dev if Udev is not running,
+# and sets the real-time scheduling latency.
+#
+# Written by Romain Lenglet [EMAIL PROTECTED].
+#
+
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+NAME=xenomai
+DESC=Xenomai
+
+# Include xenomai defaults if available
+if [ -f /etc/default/xenomai ] ; then
+ . /etc/default/xenomai
+fi
+
+# Set default values in case /etc/default/xenomai does not exist or is not
+# correctly specified
+GROUP=${GROUP:=root}
+MODE=${MODE:=0770}
+LATENCY=${LATENCY:=0}
+
+set -e
+
+case $1 in
+ start|reload|restart|force-reload)
+ echo -n Starting $DESC:
+
+ # Create devices if Udev is not running (otherwise, Udev should have
+ # been configured to create the devices itself).
+ UDEV_STARTED=N
+ if [ -e /dev/.udev ]; then
+ if mountpoint -q /dev/; then
+ UDEV_STARTED=Y
+ fi
+ fi
+ if [ $UDEV_STARTED = N ]; then
+ for N in `seq 0 31`; do
+ F=/dev/rtp$n
+ if [ ! -c $F ]; then
+ /bin/mknod -m 666 $F c 150 $N
+ /bin/chown :$GROUP $F
+ /bin/chmod $MODE $F
+ fi
+ done
+ F=/dev/rtheap
+ if [ ! -c $F ]; then
+ /bin/mknod -m 666 $F c 10 254
+ /bin/chown :$GROUP $F
+ /bin/chmod $MODE $F
+ fi
+ echo -n devices,
+ fi
+
+ # Set the scheduling latency.
+ if [ -w /proc/xenomai/latency ]; then
+ echo $LATENCY /proc/xenomai/latency
+ echo -n latency,
+ fi
+
+ echo done.
+ ;;
+ stop)
+ echo -n Stopping $DESC:
+
+ # Delete devices if Udev is not running.
+ UDEV_STARTED=N
+ if [ -e /dev/.udev ]; then
+ if mountpoint -q /dev/; then
+ UDEV_STARTED=Y
+ fi
+ fi
+ if [ $UDEV_STARTED = N ]; then
+ for N in `seq 0 31`; do
+ F=/dev/rtp$n
+ if [ -c $F ]; then
+ rm -f $F
+ fi
+ done
+ F=/dev/rtheap
+ if [ -c $F ]; then
+ rm -f $F
+ fi
+ echo -n devices,
+ fi
+
+ echo done.
+ ;;
+ *)
+ N=/etc/init.d/$NAME
+ echo Usage: $N {start|stop|reload|restart|force-reload} 2
+ exit 1
+ ;;
+esac
+
+exit 0
diff -Naurd xenomai/scripts/etc/README xenomai-new/scripts/etc/README
---
Re: [Xenomai-core] prepare-kernel.sh patch to factorize generated patches
Romain Lenglet wrote: Hi, I have added two new command-line options to prepare-kernel.sh to filter the changes to record in the generated patch files. The patch to prepare-kernel.sh is attached. Applied, thanks. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: AW: [Xenomai-core] Fundamental Questions
In light of the desire for support below, would the Xenomai team consider listing companies capable of commercial support on their website, or create another mailing list for us to announce commercial offerings around Xenomai. I amprepared to contribute to Xenomai in order to receive this privilege. Sorry for discussing commercial issues on your mailing list. If it makes it any better, we are a very small company, just trying tomake a living,not a big corporate conglomerate. As a final point, I believe Xenomai is very well positioned to become very popular and "future proof". I believe the next frontier for Linux is industrial grade Linux, or Linux on the factory floor and Xenomai will end up the technology of choice to make that happen. Contrary to many opinions I have heard, I beleve the rt-preempt work done by Ingo Molnar will enhance Xenomai and not replace it.I alsothink the break from RTAI was very smart as it has given you the flexibility to move Xenomai in the direction it needs to go. The recent releases have made Xenomai ready for the commercial world. So, kudos to the Xenomai team. You guys are proving to be great leaders with the right technology at the right time.Cheers, Chris Stone.[EMAIL PROTECTED] wrote: Dear Jan,thank you for taking time to answer my questions and sorry for the delayed response, but I have been busy with some other work. Please find my follow-up questions inserted in the text.1.) Essentially the question deals with the problem, how long a Xenomai task in secondary mode can be delayed by normal Linux tasks. In detail : we plan to to have a lot of "near realtime" ethernet communication from within Xenomai using the normal Linux network stack (calling the normal socket API). The question now is, how our network communication is influenced by other Linux tasks performing also network communication, let´s say an FTP transfer ? Depending on the "normal" networking load, you will suffer from more or less frequent (indeterministic) packet delays. Do you have an idea about the dimension weare talking about :less than a millisecond, few milliseconds, seconds, or is thedelay complete indeterministic ? Xenomai will not improve this in any way. If your task in secondary mode tries to send some data and requires to take a networking lock currently held by another Linux task, it can take a real long time until this request is completed. But at least, after a (linux-)systemcall (from what task ever) finished, Xenomai gets controll back before any other linux task, isn´t it ?This means : between systemcalls a rescheduling back to Xenomai is performed or isn´t it ??Sorry for the next stupid question, but what is a network lock. With what kind of action a task can lock the complete stack ? And how long could it block the stack ?Could you give me an example for better understanding ? This gets better with PREEMPT_RT but still remains non-RT because the Linux networking stack is not designed for hard real-time. Next stupid question : what is PREEMPT_RT ? Is this kernel 2.6 or is it the Monta Vista approach for real time (making the kernel more preemtable) ? If you communication can be soft-RT, you could indeed avoid the separation - but you will then have to live with the side effects. All you can do then is try to lower the number of deadline misses by keeping the standard network traffic low and managing the bandwidth of the participants (the Linux network stack has some support for QoS, at least 2.6 I think). BTW, as long as your network is not separated or you have no control over the traffic arriving at your system, picking the Linux stack in favour of RTnet (which is compatible with non-RT networks) is indeed generally recommended. This way you keep indeterministic load away from the real-time subsystem. Unfortunatelly we don´t want to limit non realtime traffic, we just want to make shure, that deterministic traffic has a higher priority than non RT traffic (like in other RTOS like vxWorks). Indeterministic traffic should get just the leftover bandwith.What do you mean with : "Rtnet is compatible with non-RT networks" ? I thought RTnet uses a time slice mechanism and therefore could not be mixed with systems transmitting when ever they want. Do you refer to VNICs ?I have created a scheduling scenario and I would ask you to have a look on it and to tell me whether it is correct or not. Thank you ! An corresponding question about this scheduling is : are there differences between a 2.4 and 2.6 Linux kernel ? (for our PowerPC plattform we intend to use the 2.4 kernel for performance reasons)Scheduling scenario : (I hope formating is not destroyed by email transfer)Time moves downwardsv-Xenomai v-Linux kernel v-Linux processesl1 Linux task1 running s1 l1 Linux task1 makes systemcall s1 Linux task1 systemcall processed - Linux scheduling l2 Linux task2 starts to run s2 l2 Linux task2 makes
Re: [Xenomai-core] Error on rtdm skin with --enable-dox-doc
Rodrigo Rosenfeld Rosas wrote: Hi Jan, When compiling svn xenomai I noticed the following error with --enable-dox-doc switch: CC [M] kernel/xenomai/skins/rtdm/drvlib.o kernel/xenomai/skins/rtdm/drvlib.c:1513:1: error: unterminated #ifdef I just passed this stage with trunk revision 671 without problems (doxygen 1.4.4). Moreover, there is no #ifdef or related preprocessor stuff in the latest drvlib.c at line 1513. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Error on rtdm skin with --enable-dox-doc
Rodrigo Rosenfeld Rosas wrote: Em Quarta 08 Março 2006 14:35, Jan Kiszka escreveu: Rodrigo Rosenfeld Rosas wrote: Hi Jan, When compiling svn xenomai I noticed the following error with --enable-dox-doc switch: CC [M] kernel/xenomai/skins/rtdm/drvlib.o kernel/xenomai/skins/rtdm/drvlib.c:1513:1: error: unterminated #ifdef I just passed this stage with trunk revision 671 without problems (doxygen 1.4.4). Moreover, there is no #ifdef or related preprocessor stuff in the latest drvlib.c at line 1513. I think I still didn't learn how to use the svn tool. I downloaded xenomai today with (xenomai dir already existed) svn co http://svn.gna.org/svn/xenomai/trunk xenomai svn update should already be enough, no need for yet another checkout. svn status can show you if you have local differences or even conflicts. And I got 670 revision. Then I renamed xenomai to xenomai.old and did the same command again. Then I got the 671 revision and that is working fine with --enable-dox-doc. Thanks, Rodrigo. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: AW: [Xenomai-core] Fundamental Questions
Christopher Stone wrote: In light of the desire for support below, would the Xenomai team consider listing companies capable of commercial support on their website, or create another mailing list for us to announce commercial offerings around Xenomai. I am prepared to contribute to Xenomai in order to receive this privilege. We had such a page on the old RTAI site, though not really populated I think to remember. I personally have no concerns creating such a forum for Xenomai as well. I think we could start with a link sub-page on xenomai.org. Sorry for discussing commercial issues on your mailing list. If it makes it any better, we are a very small company, just trying to make a living, not a big corporate conglomerate. I'm convinced that this is not a question of big or small. There should just be a good balance between taking and giving. As a final point, I believe Xenomai is very well positioned to become very popular and future proof. I believe the next frontier for Linux is industrial grade Linux, or Linux on the factory floor and Xenomai will end up the technology of choice to make that happen. Contrary to many opinions I have heard, I beleve the rt-preempt work done by Ingo Molnar will enhance Xenomai and not replace it. I also Yep, that is one important point why Xenomai is future-proof in my eyes. The day may come when significant parts of the PREEMPT_RT effort are merged into mainline. But then Xenomai will still be able to offer either staged degrees of hard-RT side by side with that approach, or become a wrapping layer on top of the new deterministic and fast infrastructure (PREEMPT_RT + RT-extended glibc). No one should expect that this will happen soon, PREEMPT_RT has just started its tricky way into the kernel. think the break from RTAI was very smart as it has given you the flexibility to move Xenomai in the direction it needs to go. The recent releases have made Xenomai ready for the commercial world. So, kudos to the Xenomai team. You guys are proving to be great leaders with the right technology at the right time. This nice compliment clearly has to be passed to our smart maintainer! Jan PS: Do you already have specific plans for potential contributions? I'm just curious. signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
RE: AW: [Xenomai-core] Fundamental Questions
I do not have specific plans. I am working on something I am currently calling the Xen Loadable Module or XLM. It is an Xenomai application that when loaded, turns the Linux kernel into a Xen compatible hypervisor. For the rationale behind it see here: http://www.openembedded.biz/content/view/36/27. When it is ready, in 6 to 8 weeks, I am prepared to contribute it. It is a significant work, but, is an Xenomai application, so I don't know if you guys want it. It does fit with your goals with respect to industrial grade Linux. I think that XLM actually illustrates a key point that people forget when they compare rt-preempt to Xenomai. I believe that in the industrial grade Linux world, the ability to support multiple OS's is key, especially in light of the emerging dual core CPU's. Due to ADEOS, Xenomai has the infrastructure to support doing things like running eCos on one core and Linux on the other, or eCos and Linux, side by side, on the same CPU. XLM is designed to make this easy. Rt-preempt has no such capability. I am not trying to discredit rt-preempt. It is a significant and useful piece of work and contains some pretty smart coding. However, in my view, rt-preempt is just part of the solution required for industrial grade linux. Things like rt-preempt, Xenomai, and hopefully XLM will all be pieces of a comprehensive industrial grade linux solution. If XLM is not a suitable contribution to Xenomai, then, I can contribute other ways such as other feature development or bug fixing. I would need some direction from the leaders in order to contribute in that way. Cheers, Chris. Christopher Stone Principal Sombrio Systems Inc. www.openembedded.biz 613-831-1892 -Original Message- From: Jan Kiszka [mailto:[EMAIL PROTECTED] Sent: March 8, 2006 1:18 PM To: [EMAIL PROTECTED] Cc: xenomai-core@gna.org Subject: Re: AW: [Xenomai-core] Fundamental Questions Christopher Stone wrote: In light of the desire for support below, would the Xenomai team consider listing companies capable of commercial support on their website, or create another mailing list for us to announce commercial offerings around Xenomai. I am prepared to contribute to Xenomai in order to receive this privilege. We had such a page on the old RTAI site, though not really populated I think to remember. I personally have no concerns creating such a forum for Xenomai as well. I think we could start with a link sub-page on xenomai.org. Sorry for discussing commercial issues on your mailing list. If it makes it any better, we are a very small company, just trying to make a living, not a big corporate conglomerate. I'm convinced that this is not a question of big or small. There should just be a good balance between taking and giving. As a final point, I believe Xenomai is very well positioned to become very popular and future proof. I believe the next frontier for Linux is industrial grade Linux, or Linux on the factory floor and Xenomai will end up the technology of choice to make that happen. Contrary to many opinions I have heard, I beleve the rt-preempt work done by Ingo Molnar will enhance Xenomai and not replace it. I also Yep, that is one important point why Xenomai is future-proof in my eyes. The day may come when significant parts of the PREEMPT_RT effort are merged into mainline. But then Xenomai will still be able to offer either staged degrees of hard-RT side by side with that approach, or become a wrapping layer on top of the new deterministic and fast infrastructure (PREEMPT_RT + RT-extended glibc). No one should expect that this will happen soon, PREEMPT_RT has just started its tricky way into the kernel. think the break from RTAI was very smart as it has given you the flexibility to move Xenomai in the direction it needs to go. The recent releases have made Xenomai ready for the commercial world. So, kudos to the Xenomai team. You guys are proving to be great leaders with the right technology at the right time. This nice compliment clearly has to be passed to our smart maintainer! Jan PS: Do you already have specific plans for potential contributions? I'm just curious. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RTDM mmap and vm_operations
Hi Jan, Is there a way of knowing what was the src_addr or pptr data passed to rtdm_mmap_to_user without using the vm_private_data struct? I mean, can I obtain those information directly in the vma struct passed to the close handler? If so, I could pass a more generic struct to vm_private and use those information,making my life a bit easier... :) Thanks in advance, Rodrigo. ___ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Error on rtdm skin with --enable-dox-doc
Gilles Chanteperdrix wrote: Jan Kiszka wrote: Rodrigo Rosenfeld Rosas wrote: Hi Jan, When compiling svn xenomai I noticed the following error with --enable-dox-doc switch: CC [M] kernel/xenomai/skins/rtdm/drvlib.o kernel/xenomai/skins/rtdm/drvlib.c:1513:1: error: unterminated #ifdef I just passed this stage with trunk revision 671 without problems (doxygen 1.4.4). Moreover, there is no #ifdef or related preprocessor stuff in the latest drvlib.c at line 1513. I have a few warnings with doxygen 1.4.2: ksrc/skins/rtdm/drvlib.c:151: Warning: Member rtdm_task_destroy found in multiple @defgroup groups! The member will be put in group rtdmtask, and not in group rtdmtask That's totally weird: You are in rtdmtask, and not in rtdmtask!? Even more confusing, there is only a single @defgroup rtdmtask in the code. I think I said this before: doxygen's error reporting sucks! I'm not excluding that something is broken here, but I don't know where to look. Could anyone of you try some older revisions of drvlib.c and rtdm.h/rtdm_driver.h to check where the regression(?) may come from? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Error on rtdm skin with --enable-dox-doc
Jan Kiszka wrote: Rodrigo Rosenfeld Rosas wrote: Hi Jan, When compiling svn xenomai I noticed the following error with --enable-dox-doc switch: CC [M] kernel/xenomai/skins/rtdm/drvlib.o kernel/xenomai/skins/rtdm/drvlib.c:1513:1: error: unterminated #ifdef I just passed this stage with trunk revision 671 without problems (doxygen 1.4.4). Moreover, there is no #ifdef or related preprocessor stuff in the latest drvlib.c at line 1513. I have a few warnings with doxygen 1.4.2: ksrc/skins/rtdm/drvlib.c:151: Warning: Member rtdm_task_destroy found in multiple @defgroup groups! The member will be put in group rtdmtask, and not in group rtdmtask But the --enable-dox-doc flag should not have any influence on kernel compilation. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai as module changing bzImage
Rodrigo Rosenfeld Rosas wrote: Hi Philippe, I disabled the kernel .config support, recompiled the kernel with latest ipipe patch and rebooted my system (Xenomai configured as a module). Then I downloaded last svn Xenomai. Compiled it (after correcting drvlib.c of rtdm skin) and noted that it has changed the kernel bzImage too, besides building the modules. Although I can use the new Xenomai modules without rebooting my system, I can not understand why should bzImage change. Have you any idea? Even if you turn on module support for all Xenomai components in the 2.1 series, there are still some bits (the HAL) being compiled directly into kernel. So, any modification of headers etc. may trigger a recompilation although the binary output will be the same. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTDM mmap and vm_operations
Rodrigo Rosenfeld Rosas wrote: Hi Jan, Is there a way of knowing what was the src_addr or pptr data passed to rtdm_mmap_to_user without using the vm_private_data struct? I mean, can I obtain those information directly in the vma struct passed to the close handler? If so, I could pass a more generic struct to vm_private and use those information,making my life a bit easier... :) I do not see a clean, official way right now. It would definitely be something you have to obtain via vma_area_struct or something that's contained in it. The information is likely there - somewhere. But I doubt that obtaining it would make your code very portable across different kernel versions. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: AW: [Xenomai-core] Fundamental Questions
Christopher Stone wrote: I do not have specific plans. I am working on something I am currently calling the Xen Loadable Module or XLM. It is an Xenomai application that when loaded, turns the Linux kernel into a Xen compatible hypervisor. For the rationale behind it see here: http://www.openembedded.biz/content/view/36/27. When it is ready, in 6 to 8 weeks, I am prepared to contribute it. It is a significant work, but, is an Xenomai application, so I don't know if you guys want it. It does fit with your goals with respect to industrial grade Linux. I think that XLM actually illustrates a key point that people forget when they compare rt-preempt to Xenomai. I believe that in the industrial grade Linux world, the ability to support multiple OS's is key, especially in light of the emerging dual core CPU's. Due to ADEOS, Xenomai has the infrastructure to support doing things like running eCos on one core and Linux on the other, or eCos and Linux, side by side, on the same CPU. XLM is designed to make this easy. Rt-preempt has no such capability. Sounds interesting, especially when considering future systems with hardware support for virtualisation, thus removing the need to patch the guest OS (there are still people with the desire to run Windows aside the RTOS core for visualisation etc.). And if your approach have real advantages over Xen, specifically on embedded systems or in combination with hard real-time, this could become really great. I am not trying to discredit rt-preempt. It is a significant and useful piece of work and contains some pretty smart coding. However, in my view, rt-preempt is just part of the solution required for industrial grade linux. Things like rt-preempt, Xenomai, and hopefully XLM will all be pieces of a comprehensive industrial grade linux solution. If XLM is not a suitable contribution to Xenomai, then, I can contribute Let's wait for some code first so that things like intrusiveness etc. can be analysed. other ways such as other feature development or bug fixing. I would need some direction from the leaders in order to contribute in that way. It's often best to pick a domain you are interested in on your own. This can drive the overall development application-oriented in a very constructive way. When you are using Xenomai for some projects, you may happen to stumble over rough edges or lacking features. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: AW: [Xenomai-core] Fundamental Questions
On Wed, 8 Mar 2006, Jan Kiszka wrote: Christopher Stone wrote: I do not have specific plans. I am working on something I am currently calling the Xen Loadable Module or XLM. It is an Xenomai application that when loaded, turns the Linux kernel into a Xen compatible hypervisor. For the rationale behind it see here: http://www.openembedded.biz/content/view/36/27. When it is ready, in 6 to 8 weeks, I am prepared to contribute it. It is a significant work, but, is an Xenomai application, so I don't know if you guys want it. It does fit with your goals with respect to industrial grade Linux. I think that XLM actually illustrates a key point that people forget when they compare rt-preempt to Xenomai. I believe that in the industrial grade Linux world, the ability to support multiple OS's is key, especially in light of the emerging dual core CPU's. Due to ADEOS, Xenomai has the infrastructure to support doing things like running eCos on one core and Linux on the other, or eCos and Linux, side by side, on the same CPU. XLM is designed to make this easy. Rt-preempt has no such capability. Sounds interesting, especially when considering future systems with hardware support for virtualisation, thus removing the need to patch the guest OS (there are still people with the desire to run Windows aside the RTOS core for visualisation etc.). And if your approach have real advantages over Xen, specifically on embedded systems or in combination with hard real-time, this could become really great. I have the same positive reaction towards this XLM suggestion! In some of our projects with machine tool builders, this kind of virtualization is high on their wish list, because it's a perfect way (hopefully) to combine lots of legacy GUI code with the advantages of a realtime Linux-based controller. Herman -- K.U.Leuven, Mechanical Eng., Mechatronics Robotics Research Group http://people.mech.kuleuven.be/~bruyninc Tel: +32 16 322480 Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Anybody Has Sample Code of Message Queue Performance Measurement in User Space for Xenomai Native Mode?
We are in the process of calibrating Xenomai native API message queue performancein user space application. Does anybody has sample code to share with us? ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Small doc fix for rtbenchmark.h
Sebastian Smolorz wrote:
Hi Jan,
here is a fix for the following doxygen warning:
xenomai/include/rtdm/rtbenchmark.h:146: Warning: end of file while inside a
group
Sebastian
--- xenomai/include/rtdm/rtbenchmark.h2006-03-09 01:13:40.0
+0100
+++ rtbenchmark.h 2006-03-09 01:13:24.0 +0100
@@ -138,6 +138,7 @@ typedef struct rtbnch_trace_special {
#define RTBNCH_RTIOC_SPECIAL_TRACE_EX \
_IOW(RTIOC_TYPE_BENCHMARK, 0x25, struct rtbnch_trace_special)
+/** @} */
/** @} */
Yep, indeed - fixed. Might explain some of the other problems that
popped up today, err, yesterday...
Thanks,
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
