Hello Cort,
You're somewhat right. There are hardware issues that may be out
of the reach of any software, the PCI stall example is a good
one. On the other, whether RTLinux is running on Alpha, MIPS or
PowerPC, device drivers can still issue the equivalent cli/sti
and ruin determinism. There's nothing RTLinux can do about it.
Best regards,
Karim
Cort Dougan wrote:
>
> } > This approach appears to handle some of the weaknesses of the RTLinux
> } > method; namely that a binary module can still contain the cli/sti
> } > instructions and destroy the determinism. In fact, even a user mode
> } > program with root permissions can do the same. The best example is
> } > some of the X servers.
> }
> } I hadn't thought of this particularly, but you are correct by saying
> } that this is a shortcoming of the RTLinux method.
>
> I think this is a combination of weaknesses, not all of which are
> characteristics of the RTLinux approach.
>
> X, running as root or not, cannot have a cli/sti in them unless X is
> executing in kernel mode (not user mode), which it does not do. Old
> versions of X did use ioperm, and linux/x86 allowed that. I think that's a
> weakness of the x86, not the RTLinux approach itself. Alpha, MIPS and
> PowerPC RTLinux approaches don't suffer from this problem.
>
> Current versions of X (4.x) are pretty aggressive with cards that are not
> entirely spec which results in PCI stalls. That's a problem for any
> real-time system since software can't do much about this once it's
> happened.
--
===================================================
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===================================================
-- [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/
