On Tue, 27 Nov 2001, Roland Bengtsson wrote:

> http://www.qnx.com/literature/whitepapers/reallinux.html. They said of
> course that their solution is the best:-)
That is normal statement. Whay would they say that somebody has a better
solution than QNX.

> main disadvantages of RTLinux is:
>
> 1. Duplicated coding effort. As there are two kernels running there's a
> need for drivers

That is partly correct,

>       in the realtime kernel if the service want be deterministic. This
> means also that more memory is needed for the extra code.

Is cheap these days.

> 2. Realtime tasks aren't protected by a MMU like ordinary Linux-tasks.

Protected from each other? Yes.

> 3. Limited portability of realtime tasks.

Portability to what? Real time tasks are very hardware and runtime system
dependent.

> shortcomings in QNX as this is two different approaches on the same

How will that help your evaluation?

> 1. What are the main reason that the standard Linux-kernel isn't
> preemptable from the beginning?

It is a general purpose OS.

> 2. Realtimetasks all share their userspace and aren't memprotected, right?

Real time tasks share the kernel address space (think threads) and Linux
kernel is monolithic -- a large address space..

> Isn't it possible to implement this in   some way. Honestly I don't think
> RTLinux will success in critical processes if this situation remain.

Your insight into the future is noted.

>
> 3. "Hardware context switching provided by x86 is not used."  This sentence
> is from page 14 on http://www.rtlinux.org/documents/RTLinux.ppt. Is there
> any reason for this?

No comments on this one. Maybe a better person will reply to this others.

-ishwar

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

Reply via email to