On Tue, Nov 27, 2001 at 11:38:37PM +0100, Roland Bengtsson wrote:
> Hi, I'm a student from Sweden that study computer science att Halmstad
> H�gskola http://www.hh.se/english.
> I would be thankful if someone would take the time and give your view of
> this.
>
> Right now I'm writing a paper about Linux and realtime. I'm trying to give
> a brief overview of what is available today and what the future have in
> mind. I also try to explain the technical differences between the systems,
> advantages and disadvantages. I have read a paper from QNX
> http://www.qnx.com/literature/whitepapers/reallinux.html. They said of
> course that their solution is the best:-)
>
> Even if they don't mention RTLinux directly it's obvious that they mean
> RTLinux when they compare different solutions. In short they say that the
> main disadvantages of RTLinux is:
>
> 1. Duplicated coding effort. As there are two kernels running there's a
> need for drivers
> in the realtime kernel if the service want be deterministic. This
> means also that more memory is needed for the extra code.
This applies better in reverse: if there is one kernel, and it supports non-
RT services, there must be non-RT drivers in the RTkernel duplicating
code that is found in Linux already (better and done by a larger
community) and, more importantly, the core kernel code paths have to
include both RT and non-RT paths wasting memory and time.
> 2. Realtime tasks aren't protected by a MMU like ordinary Linux-tasks.
The mmu issue is complex.
The earliest RTLinux implementation by Michael used system
calls and ran the RT task in user space. Measurements showed
performance loss and our goal was (and is) best-of-breed
performance. We also reasoned as follows: if you are using RT
code to control a machine tool (for example) and you have a bug
in your code in which a wild pointer hammers memory, your
machine tool will fail whether or not there is memory protection
and that failure may involve high speed projectiles So
mmu -> performance loss + no appreciable safety
improvment
Choice is obvious - no?
However, there are countervailing arguments. For some
applications there are soft landings and some applications
consist of a mix of trusted and untrusted code. For example,
you might have a fail-safe mode in a small core piece and
a non-fail-safe mode in "drivers" and have the fail-safe
piece run if the drivers screw up. I'm not sure I believe this
fully, but it's semi-compelling. Also debugging is simpler with
user mode. And there is a question of using e.g. graphics
libraries that we don't want to import into kernel mode.
The RTAI folks implemented LXRT and showed that there was strong
utility to some user mode real-time in our model. But getting
(A) the API right (B) the interface portable (C) the
implementation memory safe all looked like too much work.
We then did the rtl_sigaction to allow for RT user mode signal
code in RTL/GPL but this got little user response and only one
user as far as I know and it turned out to be hard to maintain
and extend. So we have done a second phase
user mode RT in RTLinux/Pro because we got
a sponsor or two, but it has been a lot of work as expected.
(free licenses for educational use are available: works on
PowerPC and x86 and does SMP)
> 3. Limited portability of realtime tasks.
> etc.
Au contraire. The RT code is pthreads. The non-RT code is UNIX.
>
> It was interesting to see your view of this and maybe if you have som
> shortcomings in QNX as this is two different approaches on the same
> problem. And now my own questions about RTLinux...
>
> 1. What are the main reason that the standard Linux-kernel isn't
> preemptable from the beginning?
> Performance?
Better design. Dennis Ritchie made UNIX non-preemptable so that
the kernel would spend time working on user requests instead of
locking and unlocking its own data structures and this decision
has been many times validated.
Preemptible general purpose operating systems are a mess.
> 2. Realtimetasks all share their userspace and aren't memprotected, right?
> 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.
See above. RT is a wide area. I think that for the original
application domain, instrumentation and simple machine control,
shared memory space is the correct design. For some other spaces
including large scale simulations where one can use high power
processors big caches etc and where timing is not pushed to the
wall, user mode is ok. BUT one of the biggest problems with RT
is that RT has stark and inescapable tradeoffs and limits that
are psychologically difficult to accept. A stray pointer in a
control application will cause a timing error and if the timing
is critical, no memory manager can help you.
> 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?
Performance
>
> Regards Roland
>
> -- [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/
-- [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/
