Sender: |
|
Date: |
Fri, 9 Jun 2000 11:37:57 -0400 |
Reply-To: |
|
Subject: |
|
MIME-Version: |
1.0 |
Content-Transfer-Encoding: |
7bit |
Content-Type: |
text/plain; charset=us-ascii |
Organization: |
Boolean Solutions, Ltd. |
From: |
|
Parts/Attachments: |
|
|
"Kester, Rush W." wrote:
> The drawback are that a successful RTOS requires a high level of
> support (IMO impossible with volunteers). It also fails the "killer
> app" requirement that no existing success products are already on the
> market.
>
> Doesn't Linux meet your criteria for Open Source? Linux is very Ada
> friendly and is being adapted for use with embedded systems (e.g.,
> HardHat Linux, BlueCat Linux, etc.).
Having just completed such a project, let me make a few observations.
Linux is not a real-time OS and extensions to the scheduler do not make
it so. One problem lies with the device drivers. In general their timing
behaviour is erratic making it difficult to use Linux in a hard real
time mode. The coding of many driver is quite poor and many old drivers
have never been updated (redesigned) to use new kernel features such as
kernel level tasking.
Another problem area lies with the tasking implementation. Linux treats
each task (thread) as a separate process and uses the process scheduling
algorithms to schedule both threads and processes. While this is easy
way to inject multi-tasking, it leads to difficulties. In many RTOS
systems, when a task yields and time remains in the process's timeslice,
control passes to any other ready task within the process. However Linux
treats a task yield as if the process yielded and now performs a
complete schedule evaluation. Control can transfer to another task in
another process. Hence processes with large number of tasks are penalize
relative to processes with no tasks.
The other drawback with the Linux technique is that is takes significant
time to evaluate the scheduling database and make a selection. The
tools also begin to suffer since now a PS command may have to display
several hundred threads in addtion to the normal dozen or so processes.
My experience indicates that Linux designers only expect to see a few
tasks not the dozens of tasks typical of large real-time systems.
It is interesting to note that RTOS's is one of the few areas left where
one can innovate in operating system design and there are openings for
small firms (though long time survival is doubtful). Ada is an ideal
vehicle for such work but suffers from the lack of Ada compilers for
small systems, such as Intel 8086, 8051, HC6811s, and so forth.
For more stimulus take a look at: VSTa (ftp://ftp.zendo.com/vsta/) which
is a small 80x86 microkernel and is written in GCC-C with assembler
extensions; the Flux OSKit (ftp://flux.cs.utah.edu/flux/oskit) which is
a series of libraries building operating systems on 80x86 systems;
Cygnus ECos (http://www.cygnus.com) for an Open System RTOS; and RTEMS
(www.rtems.com).
David J.A. Koogler
Boolean Solutions, Ltd.
|
|
|