LXRT for PPC

[Paolo Mantegazza]

wolfgang.grandegger at bluewin.ch wrote:
> 
> >-- Original Message --
> >From: Vincent Nollet <vincent.nollet at imec.be>
> >To: rtai at rtai.org
> >Subject: LXRT for PPC
> >Date: Wed, 06 Nov 2002 12:01:59 +0100
> >
> >
> >Hello,
> >
> >I was just wondering ... is anyone busy on LXRT for PowerPC (PPC 405) ?
> 
> I'm not busy on LXRT for PowerPC and I do not know about anybody
> else. It does not even have a very high priority. Following the
> new developments, e.g. RTAI over ADEOS seems more important and
> to me.
> 

That is true as ADEOS might be of futher help in LXRT ports. Nonetheless
if one wants to work on any new LXRT port there is no need to wait.

In fact, FYI, I know that LXRT has already been ported to MIPS but I've
no idea of when it will be made public. That would be useful as it would
help to make the code less machine dependent, further fostering any
port.

In any case on CPUs with a reasonable power, say starting with old plain
200 MHz Pentiums, I'd rather work on porting NEWLXRT directly. Where
would PPC 405 stand?

It should be easier as it has proven to be capable of more Linux code
reuse, read it less patching, and newlxrt.c has shrinked a lot, the core
of it all being in its scheduler. Since NEWLXRT is younger any further
port will be of great help in having it stabilised in a shorter time.
Recall that NEWLXRT schedules Linux object directly, i.e. Linux user
space tasks and kernel threads. It can be seen as just a standard Linux
extension, since there are no RTAI specific kernel space tasks anymore.

LXRT is there to stay but if ported to other archs, with NEWLXRT
available, its use will make more sense on low end CPUs working mainly
with RTAI proper kernel tasks and some hard/soft real time user space
activity.
Instead on reasonably high end systems, at least of the type hinted
above, I'm loosing sight of any need to use RTAI specific kernel tasks;
kernel threads can be an adequate substitute, if needed at all. It must
be remarked that the hard real time bottleneck of any high end general
purpose CPU is not user space but its architecture. It is easy to check
it out that the worst case latency is the same in kernel and in user
space. In any case on higher end CPUs the execution of any RTAI APIs
will be just a negligible fraction of the worst case jitter, enough to
make little sense in minding any overhead difference between kernel/user
space.

What said is mainly based on DIAPM experience that, following the
appearance of RTW support, has shown no kernel space need since more
than a year ago, without any feeling of performance losses. Lowest
machine in use PIII 600 Mhz.

Paolo.