> ------------------------------------------------------------------------
> | | 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/
