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].
[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?
I don't know of any current effort regarding this.
If not, I can start it. What should be the name of the RTAI/Classic
skin? Any advices before starting this skin?
Well, what about "classic"? The best advice I have right now from the
top of my head is: "build it step by step". I would go for enumerating
the exact features you need from 3.x, then implement the corresponding
call groups and services within them one by one with incremental tests
using the simulator for those which can be simulated (ie. almost all
except fifos and everything that really taps into specific Linux kernel
features). Enriching it later with new calls would be a piece of cake.
FYI, almost all the native API can run over the simulator this way,
another good definition of what could run over the simulator is:
"(almost) each service from any skin which is available to kernel-based
applications". The reason behind this is simple: most kernel-based API
calls cannot rely on the Linux kernel, just because they cannot re-enter
it at will to invoke regular Linux entry points synchronously during the
course of execution; only user-space tasks could do that using the
domain migration scheme. Therefore, since they must only rely on the few
abstractions provided by the nucleus instead, those abstractions can be
simulated, and actually are, by the simulation engine, because they are
conceptually simple and do not drag complex kernel mechanisms.
Under skin/rtai/doc/refactoring.txt, you will find most of the rationale
for changing syntaxes and/or semantics between 3.x and fusion we have
used during the development, and a few conversion guidelines too.
I can help setting up the simulator if you encounter problems, but on
x86, this should be fairly simple. Some std distro packages are
required, and listed in sim/READE under "Building the MVM".
Additionally, you should grab a GDB 5.3 source tarball, and a GCC 2.95.3
source tarball for building the code instrumenter. The rest is automatic.
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.
It depends; you would indeed have to solve the namespace clash in kernel
space by using another prefix than rt_ for the emulation skin (or adding
a suffix, whatever), but if running your app in user-space context is
ok, you could still keep the same function names into the interface
library invoking the emulation skin services, provided you would never
link an app with both fusion and classic skin libraries anyway.
--
Philippe.
