From: Philippe Gerum <rpm@xenomai.org>
To: "Steven A. Falco" <sfalco@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] Xenomai/SOLO - RTOS emulation for standard Linux
Date: Wed, 26 Mar 2008 19:04:18 +0100 [thread overview]
Message-ID: <47EA9022.7010504@domain.hid> (raw)
In-Reply-To: <47EA4F65.7050600@domain.hid>
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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
>
--
Philippe.
next prev parent reply other threads:[~2008-03-26 18:04 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-20 23:11 [Xenomai-core] Xenomai/SOLO - RTOS emulation for standard Linux Wolfgang Denk
2008-03-23 10:14 ` Roland Stigge
2008-03-25 22:49 ` Wolfgang Denk
2008-03-26 9:18 ` Roland Stigge
2008-03-26 13:28 ` Steven A. Falco
2008-03-26 16:20 ` Wolfgang Denk
2008-03-26 18:00 ` Roland Stigge
2008-03-26 18:04 ` Philippe Gerum [this message]
2008-03-26 19:01 ` Steven A. Falco
2008-03-28 10:17 ` Philippe Gerum
2008-03-28 20:31 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47EA9022.7010504@domain.hid \
--to=rpm@xenomai.org \
--cc=sfalco@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.