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
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.
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
[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
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
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
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,
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
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
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,
[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
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
12 matches
Mail list logo
