Miguel Simon wrote:
Dean Douthat wrote:
Miguel Simon wrote:
Please disregard point 6 in the previous post, for it does not apply. I
copied this from an old email, and point 6 escaped the ax. >:o( Thanks.
This is the actual message:
Miguel Simon wrote:
Hi every one…
I do research at school and also at my work (> www.saic.com> ). In both
fronts, I have to constantly convince people that QNX is in many aspects
a more sound choice as compared to Linux, RTLinux, etc. Some of the
reasons that I put forth are bellow. Please DO NOTICE THAT I do not
claim that Linux or RTLinux are lesser products, I just want to compile
facts that support my point that QNX is as good (if not better at times)
a choice for hard real time embedded applications as RTLinux can be.
One of the main arguements against QNX6 is that drivers are not as
widely available as they are for a Linux based application. My conter
argument is that a Linux driver can be ported over to Neutrino with
relative ease. What is your opinion + experience?
Regular Linux and its drivers are not adequate for hard realtime; the Linux
community clearly confirms this fact by the existance of RTLinux. No matter
how plentiful, RTLinux drivers are on the wrong side of the dual OS setup.
That is, they are essentially useless.
Dean, thanks for you help. Here are some questions for you. > 
Why are the RTLinux drivers on the wrong side of the dual OS setup?
They are in the regular Linux kernel, not directly accessible from the RT exec, at
least, that is my impression from reading about RTLinux. There are variations of
pipes that can communicate back to front and front to back but the indeterminism of
the desktop OS remains. Moreover, real-world applications of RTOS involve
interfacing to oddball hardware (mine, missile, robots, and the like). A
significant virtue of an RTOS is ease of writing/debugging drivers. Linux (or any
Unix) offers considerable improvement over Microsoft OS in this respect but is miles
behind what can be done with a micro-kernel such as QNX. Drivers in user space are
hard to beat; I’ve been there on both sides of the monolithic-/micro-kernel divide
and have no doubt which side is orders of magnitude better.
And by ‘dual OS’, do you mean dual in the sense that the same kernel
serves both the real-time and the soft-rt side of the generic Linux OS?
No, I mean there are two kernels, a realtime OS (or exec) in back running the
desktop OS/kernel in front as a task. Thus determinism is gained by subjugating the
desktop OS to the RT OS (or exec). This dual nature means that the learning curve
advantage of Linux for programmers, the familiar POSIX API, is lost because the back
kernel presents a radically different API. Ditto Win32 API for dual OS approaches
with Microsoft OS.
Reading the last ‘Embedded Systems’ magazine I found the article
‘Real-Time Linux’ by Alex Ivchenko
(> http://www.embedded.com/story/OEG20010418S0044> ), there is this portion:
“Indeed, many established vendors of real-time
software are migrating rapidly toward embedded Linux,
examples being QNX and Lynx Real-Time Systems; Lynx even
went as far as changing its name to LynuxWorks.”
I haven’t read this article so can’t comment. Perhaps somebody from QSSL can
comment on the “rush” away from QNX to embedded Linux; I assume they’ve noticed the
drastric drop in sales. BTW, is embedded Linux considered an RTOS?
Can you please comment on this? Given the context of the article, what
does this author mean? My point is that the people that I propose QNX
to, they all have this culture in their approach to real-time systems.
I do not necessarily wan to change their technical culture, but I do
want to be able to reply to their entrenched positions with technical
reason rather than technical tradition.
The dual OS approach of RTLinux (or Microsoft OSs) is now, once again, a hot
topic. To my recollection, this is the third time around for this idea. In
I am sorry, but what does Microsoft have to do with RTLinux?
Venturecom and others are trying the same architectural (dual OS) approach with
Micosoft Windows {NT|2000} as used for RTLinux.
the late 70s, Hans Lachlama at Bell Labs first tried this approach with a RT
kernel and Unix as a task under it. Within a couple of years, the approach
was found wanting and abandoned in favor of Plan 9. Again, in the late 80s it
surfaced and again was eventually abandoned. It seems unlikely to me that
this third time around will be charmed. Rather, I’ve noticed that this idea
resurfaces periodically whenever the previous crop of technical people move on
to management (thus attaining nearly complete memory loss) and a new crop,
lacking corporate memory, arises. My impression is that the dual OS approach
is to software as galium arsinide is to hardware: “It’s the wave of the
future; always has been and always will be.”
…and QNX is not a ‘dual OS’ because…?
I just isn’t. There is a single micro-kernel upon which all OS services are built,
that is, realtime, human interface…
As a further critique of the dual OS, applying more to those with Microsoft
OS, consider this. Either the desktop OS is critical to operation of the
realtime system or it’s not. If it is, e.g., drivers, then how can its lack
of determinism be reconciled with realtime deadlines? If not, why have it?
If (when, in the Microsoft case) it bluescreens, the entire realtime system
must be rebooted. If you want the familiar look/feel or whatever, set the
This is actually my whole point. We are developing mission critical
systems, and a rebooted system is a no-way-Jose thing. This is my
main-and-so-far-wining argument for QNX.
desktop OS up on another box communicating by ethernet or the like. Then
write your communications software to provide a “circuit breaker” against
indeterminism. Boxes are cheap; failures of realtime systems are not.
Now don’t get me started on SMP. > 
But please, do go ahead… What about SMP? You seem to imply a negative
attitude toward SMP. Why would this be a bad approach to real-time
engineering (where appropriate)?
I don’t want to divert to another large topic. Suffice it to say that the OS (blind
to the application) can never distribute tasks to load balance as well as the
application can for dedicated applications. So, Asymmetric Multi-Processing should
always do better with less overhead, again for dedicated applications.
Thanks…
Miguel.
I wonder if you would help me with what I have written bellow. If I am
mistaken please help me to get it right, and if I am right, please help
me get more technical facts. My audience is highly technical and
opinionated with a lot of decision making power (i.e. I have to help
convince them to fund our projects over a number of other very good
proposals). So feel free to be as deeply technical as you can be.
Notice that for some porjects money for OS is not much of an argument
for a number or reasons, thus the fact that Neutrino for x86 is free for
research purposes is a plus but not a decisive factor. For example, in
the defense industry VxWorks is used widely. How can I convince people
used to work with VxWorks that Neutrino is as good a choice with reasons
other than the fact that QNX6 for x86 is free for research purposes?
Thanks…
Miguel.
-
Contrary to what most people think, Neutrino code is easier to
maintain than Linux, the reason being that Neutrino is itself the RTOS
Kernel which has one single developer: QSSL. When it comes to Linux,
every body is a developer with a different agenda and flavor, which
means that there is almost not two identical systems out there.
-
A fundamental difference between Neutrino and Linux is at the Kernel
and driver level as it pertains driver development. In Linux, the
drivers are intrinsically intertwined with the kernel, and this means
that if you develop a new driver in Linux, then you have to compile the
driver along with the complete Kernel with the associated room for
error. In contrast, Neutrino is actually the Kernel (which no one ever
compiles), and any developed drivers are compiled completely independent
of the Kernel. This results in a driver that operates as another process
as far as the kernel is concerned.
-
Linux is very reliable, but Neutrino based code is more so for the
following reason: In Linux if a driver dies, so does the kernel => end
of story ==>> you need to reboot the system. In Neutrino if a driver
dies, the kernel continues on, and another process can restart the dead
driver => inherent robustness ==> never need to reboot the system.
-
Perhaps a most compelling argument for use of Neutrino is that Linux
and Neutrino are both POSIX compliant, which means that code developed
for Linux is 90% compatible with code generated for Neutrino. The
difference is, of course, that Neutrino is a true hard real-time OS
which Linux is not.
-
Neutrino is a true RTOS that can be used as a soft real-time OS if
need be. Linux can be used as a soft real-time OS which can never
be used as a hard RTOS. Using Neutrino in embedded applications just
makes sense because Neutrino was designed for embedded applications from
its birth.
–
Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/
–
Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/