Paolo Mantegazza wrote:
Fillod Stephane wrote:
Philippe Gerum wrote:
Paolo Mantegazza wrote:
Fillod Stephane wrote:
Dear RTAI/Fusion developers,
RTAI/Fusion is great, especially when legacy code has to be ported
to
it.
In my case, the legacy code is RTAI/Classic (from the 24.1.x era),
and unfortunately, none of the posix/psos+/uitron/vrtx/vxwork .. and
refactored RTAI/Fusion skins have support for it. Rem: this reminds
me
something about shoemakers ;-)
Well it looks like it's time for "a migration kit from RTAI
'classic'
to 'fusion'" as referred in this article[1].
Rem: I have to do that because of the lack of PowerPC support in
the RTAI/Classic (3.x) branch.
[1] http://www.rtai.org/modules.php?name=Content&pa=showpage&pid=5
My needs are pretty reasonable: they are a reduced set of rt_sem_*,
rt_task_*, rtf_*(RT fifos) and rt_*_irq functions.
Does anyone started already a RTAI/Classic skin for Fusion?
If not, I can start it. What should be the name of the RTAI/Classic
skin? Any advices before starting this skin?
Philippe, what would be the name of the skin(for directory and such)?
Any advice?
I understand that I won't be able to use the RTAI/Classic and
the Fusion native skins at the same time in kernel because of
namespace clash.
showroom/fusion, performances checkers.
Sorry Paolo, I don't understand what you wrote.
What is showroom/fusion ? I can't find such directory under CVS.
Sorry, but showroom/fusion cannot work as fusion does. If it did, I
would not have started this branch in the first place.
Actually it is "showroom/v3.x/user/fusion". It is a bunch of RTAI-fusion
compatibility headers that allow you to run RTAI-fusion user space
applications within RTAI-classic. At the moment is just a draft for
cross performances checking and contains RTAI-fusion switches and
latency, plus a reworked latency, using Fusion message queues. It will
be completed as time allows and poured in the official RTAI-classic
eventually.
My point was, and still is: API per-se is nothing but a window-dressing
of some sort on top of a given core. Talking about "running RTAI-fusion
user-space apps" over RTAI-classic just using some quickly crafted
syntactical wrappers is just misguiding, and for the same reason, I
never suggested that classic's API should be wrapped that way on top of
fusion's native API. Syntax will be compatible but the behaviour won't.
A neat emulation like the one Stéphane talked about is the way I'd go too.
Classic chose the "DSP-way" of providing RT services a long-time ago, in
order to get latencies close to bare metal performances with a clear
choice of ignoring Linux and this trend seems to be followed more
radically each day, with the now famous "immediate" dispatching mode I'm
really not fond of, as you know it already. OTOH, fusion made a clearly
different choice by seeking a complete integration with the Linux
environment whilst keeping high determinism and low-latencies in primary
mode. Two conceptually different approaches potentially addressing
different needs, implemented by two very different cores, and developed
according to different technical priorities.
You likely want the opposite but the same method could be applied.
Frankly, I don't care much about which way migrations are going, just
because I can't work with some "user adoption rate counter" in mind,
especially since real-time Linux is a niche, dual-scheduler approach is
a niche inside this niche, and RTAI is even a portion of the latter.
But, my point is to make this niche veee-ry comfortable for the fusion
user, and I guess you would say the same for classic.
--
Philippe.
