Re: [Xenomai-core] Xenomai/SOLO - RTOS emulation for standard Linux
Hi, Wolfgang Denk wrote: Is it worth providing a separate xenomai-solo package in Debian right now (considering it being propagated to Debian 5.0 and supported there in this form until ca. 2010), or should we wait until Xenomai/SOLO is integrated into Xenomai mainline? Integration into Xenomai mainline means waiting for Xenomai 3, which seems still a pretty long way to go. On the other hand, you need a PREEMPT_RT enhanced Linux kernel for Xenomai/SOLO to provide real-time behaviour which is probably needed in most cases when you try and emulate a RTOS. This is probably a bigger hurdle? I think an RT-patched kernel is quite common, at least if I consider the realtime conscious Debian user community. For other realtime applications such as JACK (though in a completely different application domain), the respective kernels are also often presumed. So if we are talking about Xenomai 3 in the order of years, Xenomai/SOLO as a separate package seems worth considering if it matures reasonably. The other desktop suitable approach is the simulator. Both Xenomai/SOLO and the simulator are good candidates for inclusion in the OS distribution since (apart from certain kernel requirements) they can be provided as universal binary packages in userspace. The problem with xenosim is its dependency upon gcc-2.95.6 sources. Since Debian packages must provide the complete sources for building the binary packages or alternatively/additionally have build dependencies satisfied by other (binary) Debian packages in the distribution, this is not an easy task (without gcc 2.95.x being in Debian anymore). One way to go could be utilizing a newer GCC (4.x) instead of 2.95.x, but that doesn't work with current xenosim. Is it worth it to put porting effort into this spot? Thanks! bye, Roland ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai/SOLO - RTOS emulation for standard Linux
I'll of course have to make my own tests, but I am curious - do folks expect that Xenomai/SOLO will be able to equal the interrupt performance of Xenomai/IPIPE? I guess my intuition says that the IPIPE approach would guarantee better interrupt response, but maybe my intuition is completely wrong. I'll try to post some results in a few weeks... Steve Falco ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [SOLO] Build fail due to lack file(s)
Hello list, After git pull, I found that pSOS(*) emulation interface on top of the Xenomai/SOLO framework was checked in. However, it fails to build due to lack file(s) in repository. Here are the compilation results: % make[1]: Entering directory `/tmp/xenomai-solo/psos' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../include -g -O0 -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing -D__SOLO_DEBUG__ -D__XENO__ -D__SOLO__ -Wstrict-prototypes -include xeno_config.h -I../include-MT libpsos_la-init.lo -MD -MP -MF .deps/libpsos_la-init.Tpo -c -o libpsos_la-init.lo `test -f 'init.c' || echo './'`init.c gcc -DHAVE_CONFIG_H -I. -I../include -g -O0 -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing -D__SOLO_DEBUG__ -D__XENO__ -D__SOLO__ -Wstrict-prototypes -include xeno_config.h -I../include -MT libpsos_la-init.lo -MD -MP -MF .deps/libpsos_la-init.Tpo -c init.c -o libpsos_la-init.o init.c:30:19: error: queue.h: No such file or directory init.c: In function 'PSOS_INIT': init.c:46: error: 'psos_queue_table' undeclared (first use in this function) init.c:46: error: (Each undeclared identifier is reported only once init.c:46: error: for each function it appears in.) make[1]: *** [libpsos_la-init.lo] Error 1 % Thanks, -jserv ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [SOLO] Build fail due to lack file(s)
[EMAIL PROTECTED] wrote: Hello list, After git pull, I found that pSOS(*) emulation interface on top of the Xenomai/SOLO framework was checked in. However, it fails to build due to lack file(s) in repository. Here are the compilation results: % make[1]: Entering directory `/tmp/xenomai-solo/psos' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../include -g -O0 -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing -D__SOLO_DEBUG__ -D__XENO__ -D__SOLO__ -Wstrict-prototypes -include xeno_config.h -I../include-MT libpsos_la-init.lo -MD -MP -MF .deps/libpsos_la-init.Tpo -c -o libpsos_la-init.lo `test -f 'init.c' || echo './'`init.c gcc -DHAVE_CONFIG_H -I. -I../include -g -O0 -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing -D__SOLO_DEBUG__ -D__XENO__ -D__SOLO__ -Wstrict-prototypes -include xeno_config.h -I../include -MT libpsos_la-init.lo -MD -MP -MF .deps/libpsos_la-init.Tpo -c init.c -o libpsos_la-init.o init.c:30:19: error: queue.h: No such file or directory init.c: In function 'PSOS_INIT': init.c:46: error: 'psos_queue_table' undeclared (first use in this function) init.c:46: error: (Each undeclared identifier is reported only once init.c:46: error: for each function it appears in.) make[1]: *** [libpsos_la-init.lo] Error 1 % I will commit them later today, and they should appear in the public GIT tree tonight (CET). Thanks, -jserv -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [SOLO] Build fail due to lack file(s)
In message [EMAIL PROTECTED] you wrote: After git pull, I found that pSOS(*) emulation interface on top of the Xenomai/SOLO framework was checked in. However, it fails to build due to lack file(s) in repository. Here are the compilation results: That is to be expected. The README file has a section Available emulators/APIs which only lists VxWorks so far - nothing else has been ported yet. Patches are welcome, of course :-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] Just because your doctor has a name for your condition doesn't mean he knows what it is. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [SOLO] [PATCH] Obtain proper prefix for testsuite build
Hello list, Currently, Xenomai/SOLO comes with testsuite for VxWorks emulation. The path to Xenomai/SOLO installation is fixed. The patch attempts to obtain the proper prefix during build process. Regards, -jserv diff --git a/vxworks/testsuite/Makefile b/vxworks/testsuite/Makefile index 62430ff..13ca9a0 100644 --- a/vxworks/testsuite/Makefile +++ b/vxworks/testsuite/Makefile @@ -1,4 +1,4 @@ -SOLO := /usr/local/solo +SOLO := $(shell sed -n '/^prefix/'p ../Makefile | cut -c 9-) XENO_CONFIG=$(SOLO)/bin/xeno-config prefix := $(shell $(XENO_CONFIG) --prefix) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai/SOLO - RTOS emulation for standard Linux
In message [EMAIL PROTECTED] you wrote: I'll of course have to make my own tests, but I am curious - do folks expect that Xenomai/SOLO will be able to equal the interrupt performance of Xenomai/IPIPE? I guess my intuition says that the IPIPE approach would guarantee better interrupt response, but maybe my intuition is completely wrong. I'll try to post some results in a few weeks... Well, interrupt performance is just one thing. The whole real-time behaviour depends on the underlying OS. And frankly, what we've seen so far means that PREEMPT_RT can deliver probabilistic real-time at best. Take a test case that has been running fine and just put it into a new environment (like attach it to a different network), and it will behave differently. Just plug in a new USB device that hasn't been tested before, and nobody can tell what will happen. If it comes to hard, reliable real-time behaviour, we recommend Xenomai/ipipe to all our customers. However, there are some who think it is important to have an original, unpatched kernel.org source tree. These obviously run for PREEMPT_RT, and SOLO. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] You know, after a woman's raised a family and so on, she wants to start living her own life. Whose life she's _been_ living, then? - Terry Pratchett, _Witches Abroad_ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai/SOLO - RTOS emulation for standard Linux
Wolfgang Denk wrote: If it comes to hard, reliable real-time behaviour, we recommend Xenomai/ipipe to all our customers. However, there are some who think it is important to have an original, unpatched kernel.org source tree. These obviously run for PREEMPT_RT, and SOLO. Please remember that PREEMPT_RT currently doesn't mean unpatched, so you could theoretically patch every PREEMPT_RT enhanced kernel with ipipe instead... ;- (Feelings of customers are a completely different thing, though...) Roland ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai/SOLO - RTOS emulation for standard Linux
Steven A. Falco wrote: I'll of course have to make my own tests, but I am curious - do folks expect that Xenomai/SOLO will be able to equal the interrupt performance of Xenomai/IPIPE? I guess my intuition says that the IPIPE approach would guarantee better interrupt response, but maybe my intuition is completely wrong. I'll try to post some results in a few weeks... SOLO is not about pretending that native preemption should now be the one and only solution to real-time requirements. The point is that there are different levels of real-time requirements, different real-time applications, different real-time environments. Since I just don't believe in the one-fits-it-all marketroïd message, SOLO is there to bring the Xenomai emulators to the native preemption world, because a significant portion of the application base to be migrated to Linux will be just fine in that environment. FWIW, I like the co-kernel approach for the principle of least surprise it brings with respect to latency; if the latency tests run fine, it is extremely likely that deadlines will always be met within the application, provided the latter behaves properly, even if you upgrade your target kernel. But on the other hand, I like the native preemption as well, for its ability to keep things reasonably simple when it comes to port large legacy applications, which used to rely on zillions of libraries; in that case, the necessary co-kernel/Linux programming model split is just a massive pain in the neck (i.e. primary secondary runtime modes, restriction on using the glibc in real-time mode and so on). But obviously, the co-kernel mode based on the I-pipe is here to stay, and the purpose of Xenomai 3 is to allow the emulators to be usable on top of both real-time cores (i.e. PREEMPT_RT, or I-pipe + nucleus), using a simple recompilation. SOLO is an intermediate step, before both approaches are reconciled with a common emulator code base in Xenomai 3. In other words: two real-time cores, one set of emulators. Well, that's the plan. I will send a roadmap to Xenomai 3 asap (take this literally, because of hectic schedule here), to explain where we are heading to. Steve Falco ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai/SOLO - RTOS emulation for standard Linux
Philippe Gerum wrote: But obviously, the co-kernel mode based on the I-pipe is here to stay, and the purpose of Xenomai 3 is to allow the emulators to be usable on top of both real-time cores (i.e. PREEMPT_RT, or I-pipe + nucleus), using a simple recompilation. SOLO is an intermediate step, before both approaches are reconciled with a common emulator code base in Xenomai 3. In other words: two real-time cores, one set of emulators. Well, that's the plan. I will send a roadmap to Xenomai 3 asap (take this literally, because of hectic schedule here), to explain where we are heading to. Thanks for the clarification - I was not sure of the intent for SOLO, but now it makes sense. I'm glad that IPIPE is not going away, as my application will need hard real time. Steve ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [SOLO] [PATCH] Obtain proper prefix for testsuite build
[EMAIL PROTECTED] wrote: Hello list, Currently, Xenomai/SOLO comes with testsuite for VxWorks emulation. The path to Xenomai/SOLO installation is fixed. The patch attempts to obtain the proper prefix during build process. Regards, -jserv diff --git a/vxworks/testsuite/Makefile b/vxworks/testsuite/Makefile index 62430ff..13ca9a0 100644 --- a/vxworks/testsuite/Makefile +++ b/vxworks/testsuite/Makefile @@ -1,4 +1,4 @@ -SOLO := /usr/local/solo +SOLO := $(shell sed -n '/^prefix/'p ../Makefile | cut -c 9-) XENO_CONFIG=$(SOLO)/bin/xeno-config prefix := $(shell $(XENO_CONFIG) --prefix) This won't work if you build out of the source tree like autoconf/automake recommend, since it won't find the instantiated Makefile in the upper directory. We could use an autoconf template to patch the prefix into testsuite/Makefile.in, but the testsuite/ directory is meant to be movable and compilable anywhere the user sees fit. This is basically why the Makefile has not been autoconfiscated in the first place. I guess we will have to leave with the set your Xenomai install directory for scripts and binaries in your PATH variable rule. I have removed the absolute SOLO prefix from the Makefile though, it was a left over from my development environment. Thanks for spotting this. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [SOLO] Build fail due to lack file(s)
Philippe Gerum wrote: [EMAIL PROTECTED] wrote: Hello list, After git pull, I found that pSOS(*) emulation interface on top of the Xenomai/SOLO framework was checked in. However, it fails to build due to lack file(s) in repository. Here are the compilation results: % make[1]: Entering directory `/tmp/xenomai-solo/psos' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../include -g -O0 -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing -D__SOLO_DEBUG__ -D__XENO__ -D__SOLO__ -Wstrict-prototypes -include xeno_config.h -I../include-MT libpsos_la-init.lo -MD -MP -MF .deps/libpsos_la-init.Tpo -c -o libpsos_la-init.lo `test -f 'init.c' || echo './'`init.c gcc -DHAVE_CONFIG_H -I. -I../include -g -O0 -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing -D__SOLO_DEBUG__ -D__XENO__ -D__SOLO__ -Wstrict-prototypes -include xeno_config.h -I../include -MT libpsos_la-init.lo -MD -MP -MF .deps/libpsos_la-init.Tpo -c init.c -o libpsos_la-init.o init.c:30:19: error: queue.h: No such file or directory init.c: In function 'PSOS_INIT': init.c:46: error: 'psos_queue_table' undeclared (first use in this function) init.c:46: error: (Each undeclared identifier is reported only once init.c:46: error: for each function it appears in.) make[1]: *** [libpsos_la-init.lo] Error 1 % I will commit them later today, and they should appear in the public GIT tree tonight (CET). The missing files have been committed, so they should be mirrored to the public GIT tree in a few hours from now. BIG FAT WARNING: The pSOS emulator is in its early development stage, really, badly early. It compiles, but is incomplete, and can't reasonably work properly yet. If you just want to play with SOLO, you should stick to the VxWorks emulator, which is the only one that has been officially announced so far. Of course, if you want to help debugging the new pSOS emulator, you are welcome as well (but it's still a bit early, though). -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
