Is it just me or is it time that this mailing list gets a FAQ that
deals with the differences and simularities of all the RT variants
out there (KURT, RTL, RTAI, and the commercial spin offs) ?
That way ppl don't have to keep repeating them self.
To Paolo and Victor i would like to say thanks for explaining again and
again whats RTAI and RTL are about. Even if there are differences
on the idea how to implement Realtime under linux i don't think thats
to much of a problem. When i get it right Paolo more works his way down
from aplications , while Victor works his way up from theory. But for me
as end user it should not mather how it is implemented. I only care if
it is good enough for my aplication, and if RTL isn't maybe RTAI is
and for a other apllication maybe the other way around. But to choose
i need to know which RT variant does what best. For example if i just
want
a IRQ handler it might be RTL (RTAI can do it too i know) and if i want
messaging
i might choose for RTAI.
I hope both Paolo and Victor keep concentrating on their own versions
and keep
helping each other with bug fixes and enhancements. And there better be
no race condition
between RTL and RTAI cause we all know how they end *CRASH*
- Erwin
Paolo Mantegazza wrote:
>
> > ------------------------------------------------------------------------
> > | | IPC | Semap. | Sched. | Posix | FP | OSource | Kernel | 486 |
> > ------------------------------------------------------------------------
> > | | | | | | | | | |
> > | | | | | | | | | |
> > | | | | | | | | v.6 for | |
> > | RTAI | y | y | oneshot| o | y | y | 2.2.x | y |
> > | | | | | | | | | |
> > | | | | | | | | | |
> > ------------------------------------------------------------------------
> >
> > y - embeded in the RT modules
> > n - not implemented
> > o - optional (it can be "insmod'ed" separately)
> >
> > Please, suggest other colunms and correct any thing wrong on
> > the existing ones.
>
> The above shows that the glut of information often leads to wrong
> conclusions. DIAPM was the first to introduce periodic scheduling in its
> 2.0.xx RTL variant so it is strange to see it credited with only with
> the oneshot timer.
>
> Things are this ways, it can be found in the main README file:
>
> - We have three schedulers, UP, SMP and MUP;
> - All support oneshot cpu_clock/8254 based on UP and SMP, apic based on
> SMP and MUP. In SMP you can chose between the 8254 and the local apic,
> UP is only 8254, MUP fully apic.
> - MUP allows multiple independent clocks, i.e all periodic, with
> different periods, all oneshot, mixing oneshot and periodic. An example
> we use a periodic timer on a cpu to pace a controller and a oneshot on
> the other to do PWM. There is an interesting simple trick in RTAI to
> fake the Linux while keeping its local apic work alive.
> - All the timers can be used without the scheduler to pace timer
> interrupt handlers, that often can do many things without the need of
> any scheduler. Most of the applications I see on this list seem to need
> just that and we like very much doing it in such a way.
>
> I would not say that POSIX is optional just because it needs a saparate
> insmod as it is as native as the rest of stuff. It has not been
> developped by us but is a nice contribution to RTAI from Steve
> Papacharalambous <[EMAIL PROTECTED]>. Steve has agreed to keep it is
> own way to make it easier for users willing to use just POSIX to avoid
> knowing the other parts of RTAI. (Steve correct me if I said something
> wrong) Moreover I must confess that his Makefiles are so complex for me
> that I cannot cope with them.
>
> Kernel has always been 2.1.xx, never appeared, and 2.2.xx. No backward
> compatibility, already too much work.
>
> 486 is yes just with the UP and the 8254 SMP scheduler on single cpu
> machines. I would add that it is really safe for periodic timers, in
> oneshot mode there is an annoying bug that can freeze LINUX if you ring
> the bell with the keybord.
> It will be fixed just when needed. Up to now no one required it and we
> are happy as we think that a oneshot fully based on the 8254, 486s do
> not have a cpu clock, taxes the machine to much and should not be used.
>
> At least for RTAI IPC should have also the subcases: mbox (mq) and
> intertask messages, both QNX like and not.
>
> There should be three columns more in the table.
>
> - 1) Fifos, which in RTAI are an adaption of the nice Michael original.
> RTAI should be updated to the most recent RTL ones as I saw that also
> RTL has now a similar mechanisms to avoid touching the kernel (the
> native RTAI idea).
>
> - 2) Shared memory. I like to recall that both RTL-RTAI owe it to Tomek
> Motyleswky based software, even if the user APIs are different.
>
> - 3) The possibility of using all the scheduler services also in Linux
> processes, like new system calls but without touching the kernel.
> In RTAI the same software now works Linux-Linux, Linux-RTAI and,
> naturally, RTAI-RTAI. It is a very important feature, it gives you an
> edge in developping applications as you can chose: soft rt ->
> LINUX_POSIX; firm rt (a la KURT) -> RTAI_from_LINUX, hard rt ->
> RTAI_modules, ANY_MIX.
>
> Ciao, Paolo.
> --- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> ----
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/~rtlinux/
--
Q - S O F T - E N G I N E E R I N G
Rodachtalweg 11, 81549 Muenchen, Germany
Erwin Rol (Software Engineer) phone: +49-89-68050051
[EMAIL PROTECTED] fax : +49-89-68050052
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
