Philippe Gerum wrote:
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.
Let's wait for it happily. It might be a good chance to see if our huge
core base can be used with fusion as it is.
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.
What above is OK. In fact what in magma now for x86 does not even use
the immediate way, still available, but goes to idt gates directly, and
performances do show up indeed. At the moment I still see no alternative
to RTAI-classic for DSP-like usage of the PC and is the way that will be
persued more and more as it the real need we have and will likely never
be matched by any native Linux preemption, either or not _RT.
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.
Paolo.
