technical issues...

[Miguel_Simon1]

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?

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.

\

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. Finally, if it ever comes to this, you can say with absolute
   confidence that we have solid expertise in robotic systems on land and
   in the air. If you ever see my helicopter flying its autonomous mission,
   I am sure that you would agree with me. (For example, does Benny have an
   autonomous flying helicopter in his resume?). In addition, it so
   happens that the jumping mine in which I have been working is indeed a
   robotic system. So we do actually have experience in robotic systems.

---

\

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/

[Miguel_Simon1]

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?

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.

---

1. 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.

2. 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.

3. 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.

4. 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.

5. 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/

[Kris_Eric_Warkentin]

I would be careful about some of your statements and possibly add some more.

point 1:
I don’t think you can really get away with too much comment about the
stability of the interface - after all, Linus essentially manages and keeps
veto priveleges over the Linux kernel.

point 2:
Linux device drivers can be compiled and inserted/removed into/from a running
kernel without recompiling the kernel or rebooting, however you are correct
about them running in kernel space.

Some points I might add:

1. Drivers run as regular processes and are easy to start/stop. Also, you can
   debug them using ordinary tools such as gdb rather than using the kernel
   debugger over a serial port like in Linux.

2. QNX is a LOT smaller which translates into big savings on a per unit basis.
   It may cost more to use QNX for development but if you can halve your hardware
   requirements on a million units…

3. I don’t know that much about embedding Linux but from what I understand,
   it’s much, much easier to get QNX up and running on your device because of
   the tools and support that we provide.

4. If you need real-time, you are programming to the posix layer directly.
   Some of the real-time Linux extensions involve a real-time executive which
   runs the Linux kernel as a process. This means that for real-time task,
   you’re programming towards the executive rather than the posix, and possibly
   running your real-time process in kernel space rather than in protected mode.

Someone here wrote a white-paper for a journal with a very good comparison
of the REAL cost of QNX vs. Linux in embedded applications. Maybe someone
else can reference it.

Cheers,

Kris


Miguel Simon <simon@ou.edu> 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
…

snip
…

its birth.

\

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/

–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth

[Dean_Douthat1]

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.

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
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.”

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
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.

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.

---

1. 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.

2. 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.

3. 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.

4. 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.

5. 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/

[Chris_McKillop1]

Kris Eric Warkentin <kewarken@qnx.com> wrote:

point 1:
I don’t think you can really get away with too much comment about the
stability of the interface - after all, Linus essentially manages and keeps
veto priveleges over the Linux kernel.

Actually, he really can. Between 1.0, 2.0, 2.2 and 2.4 the driver interfaces
changed. Also, MAJOR subsystems also changed. The reality is that the
Linux kernel is done by people who do things because it is fun, not because
a customer needs it. Case in point, take a look at the packet filtering
interfaces under Linux. Between every major revision that has had such
capabilites (2.0, 2.2, and 2.4) it has totally changed. The c library
is another case-in-point. Unless you are following the kernel closely
you will have issues. I would say that Linus makes sure that the kernel
doesn’t suck, but he has said many times that he is willing to change
interfaces as needed and will not provide binary backward compatibilty when
he does allow such changes.

point 2:
Linux device drivers can be compiled and inserted/removed into/from a running
kernel without recompiling the kernel or rebooting, however you are correct
about them running in kernel space.

Only if you already have support for that subsystem in place. For example,
if you didn’t build SCSI support into your first kernel you CANNOT
insert a SCSI driver module at some point in the future. Same for sound,
isdn, usb, …

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[Kris_Eric_Warkentin]

Chris McKillop <cdm@qnx.com> wrote:

Kris Eric Warkentin <> kewarken@qnx.com> > wrote:

point 1:
I don’t think you can really get away with too much comment about the
stability of the interface - after all, Linus essentially manages and keeps
veto priveleges over the Linux kernel.


Actually, he really can. Between 1.0, 2.0, 2.2 and 2.4 the driver interfaces
changed. Also, MAJOR subsystems also changed. The reality is that the
Linux kernel is done by people who do things because it is fun, not because
a customer needs it. Case in point, take a look at the packet filtering
interfaces under Linux. Between every major revision that has had such
capabilites (2.0, 2.2, and 2.4) it has totally changed. The c library
is another case-in-point. Unless you are following the kernel closely
you will have issues. I would say that Linus makes sure that the kernel
doesn’t suck, but he has said many times that he is willing to change
interfaces as needed and will not provide binary backward compatibilty when
he does allow such changes.

Are you suggesting that QNX4 and QNX6 are the same? I think that Linux is
generally pretty consistent within major revisions. Either way, I still think
that QNX is the way to go, I’m only suggesting that some points may be
somewhat questionable. I would say that QNX can stand on it’s own merits
without needing to look too hard at Linux, WinCE, etc. There really is no
comparison…

point 2:
Linux device drivers can be compiled and inserted/removed into/from a running
kernel without recompiling the kernel or rebooting, however you are correct
about them running in kernel space.


Only if you already have support for that subsystem in place. For example,
if you didn’t build SCSI support into your first kernel you CANNOT
insert a SCSI driver module at some point in the future. Same for sound,
isdn, usb, …

True but I don’t think that this really is a big thing - I think the original
point implied that you would have to recompile every time which is not the case.
I’m sure that you would know you’re doing a scsi driver and set up your kernel
appropriately.

chris

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

Kris

–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth

[Chris_McKillop1]

Kris Eric Warkentin <kewarken@qnx.com> wrote:

Are you suggesting that QNX4 and QNX6 are the same? I think that Linux is
generally pretty consistent within major revisions. Either way, I still think
that QNX is the way to go, I’m only suggesting that some points may be
somewhat questionable. I would say that QNX can stand on it’s own merits
without needing to look too hard at Linux, WinCE, etc. There really is no
comparison…>

No, but I am saying that NTO 2.0 and 2.1 are basically the same. The
driver model didn’t change (for the most part!). We don’t do the
even/odd revision numbering so that is the same as 2.2 to 2.4 for the
Linux world. We do, however, strive to keep binary compatibility between
releases. Comparing QNX4 and QNX6 isn’t very fair since they aren’t even
claiming to be the same kernel.

True but I don’t think that this really is a big thing - I think the original
point implied that you would have to recompile every time which is not the case.
I’m sure that you would know you’re doing a scsi driver and set up your kernel
appropriately.

True, but I think that this is a big deal for embedded systems in general.
You don’t want to clutter your system with things you aren’t using but
when you want to add something new you don’t want to have to worry about
changing the primary point of stability.

chris

\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[Igor_Kovalenko2]

Chris McKillop wrote:

Kris Eric Warkentin <> kewarken@qnx.com> > wrote:

Are you suggesting that QNX4 and QNX6 are the same? I think that Linux is
generally pretty consistent within major revisions. Either way, I still think
that QNX is the way to go, I’m only suggesting that some points may be
somewhat questionable. I would say that QNX can stand on it’s own merits
without needing to look too hard at Linux, WinCE, etc. There really is no
comparison…>


No, but I am saying that NTO 2.0 and 2.1 are basically the same. The
driver model didn’t change (for the most part!). We don’t do the
even/odd revision numbering so that is the same as 2.2 to 2.4 for the
Linux world. We do, however, strive to keep binary compatibility between
releases.

You need to struggle harder. The 2.1 is not backward compatible to 2.0.
Worse yet, some applications from 2.0 would execute on 2.1 without
crashing but behave incorrectly, so they are not even 100% upward
compatible. And I suppose Andrew would complain he must rebuild Lisp
every time minor revision changes or it will crash…

• igor

[Miguel_Simon1]

Kris Eric Warkentin wrote:

Chris McKillop <> cdm@qnx.com> > wrote:
Kris Eric Warkentin <> kewarken@qnx.com> > wrote:

point 1:
I don’t think you can really get away with too much comment about the
stability of the interface - after all, Linus essentially manages and keeps
veto priveleges over the Linux kernel.

Thanks for your help Chris and Kris.

Now, my point is that two developers can get the same kernel (from Linus
himself) and produce two different (and not necessarily compatible)
versions of the same ‘product’, right?. Later someone else may think
that the whole implementation is absurd, and then that new person makes
its own changes… so on and so forth. When the original set of people
get their product back fro troubleshooting… you can imagine by
yourself.

Now, the fact that someone can modify the kernel is what makes me
nervous. When I forward my development to other engineers, if something
does not work, where do we go hunting for answers?. I guess that my
point for argument will be that usually, in engineering applications you
want something to be stable, and that the underlying kernel should be
one of those things.

Actually, he really can. Between 1.0, 2.0, 2.2 and 2.4 the driver interfaces
changed. Also, MAJOR subsystems also changed. The reality is that the
Linux kernel is done by people who do things because it is fun, not because
a customer needs it. Case in point, take a look at the packet filtering
interfaces under Linux. Between every major revision that has had such
capabilites (2.0, 2.2, and 2.4) it has totally changed. The c library
is another case-in-point. Unless you are following the kernel closely
you will have issues. I would say that Linus makes sure that the kernel
doesn’t suck, but he has said many times that he is willing to change
interfaces as needed and will not provide binary backward compatibilty when
he does allow such changes.

Are you suggesting that QNX4 and QNX6 are the same? I think that Linux is
generally pretty consistent within major revisions. Either way, I still think
that QNX is the way to go, I’m only suggesting that some points may be
somewhat questionable. I would say that QNX can stand on it’s own merits
without needing to look too hard at Linux, WinCE, etc. There really is no
comparison…>

How do you educate -with very few but convincing, irrefutable words- a
Linux/WinCE cultured engineer on QNX? It is rather easy to do when you
have hard real time requirements, but when you have soft-real-time
specs, then the point is a little more weak. Thanks for your
input; I have a better feel for what others may come back to me with.

point 2:
Linux device drivers can be compiled and inserted/removed into/from a running
kernel without recompiling the kernel or rebooting, however you are correct
about them running in kernel space.

So, if I want to include a new driver for wireless comm. to a Linux box,
then I do not need to add any thing to the Linux/RTLinux kernel to do
this -‘a la QNX’? My understanding was that if a developer wanted new
features (i.e. new drivers for systems that were not there before such
as a wireless card) you needed a complete new kernel that supported the
new features. In QNX you need a new driver, but not a new kernel. Are
you telling me that the same is true in Linux/RTLinux?

Only if you already have support for that subsystem in place. For example,
if you didn’t build SCSI support into your first kernel you CANNOT
insert a SCSI driver module at some point in the future. Same for sound,
isdn, usb, …

True but I don’t think that this really is a big thing - I think the original
point implied that you would have to recompile every time which is not the case.
I’m sure that you would know you’re doing a scsi driver and set up your kernel
appropriately.

…and ‘to set up your kernel appropriately’, do you have to recompile
the kernel, or does the kernel behave pretty much like the QNX(6)
kernel? Just wondering.


Thanks…

Miguel.

–

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL


Kris

–
Kris Warkentin
kewarken@qnx.com
(613)591-0836 x9368
“You’re bound to be unhappy if you optimize everything” - Donald Knuth

[Miguel_Simon1]

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?

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?

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.”

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?

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…?

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)?

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.

---

1. 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.

2. 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.

3. 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.

4. 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.

5. 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/

[Dean_Douthat1]

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.

---

1. 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.

2. 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.

3. 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.

4. 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.

5. 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/

[Miguel_Simon1]

Dean…

Dean Douthat wrote:

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.

Thanks. I get a better picture now. If I hear you correctly, your point
is in part that writing/debugging drivers will have to be done
regardless, and doing this from a user space is by far a better option
as opposed to doing the same thing from the kernel space. This is a
fundamental point I think; I appreciate it. Thus we could argue that the
lack of wide driver availability for QNX is not as important as the fact
that available Linux drivers do operate in the kernel space, and that
the later is the greater of the two evils.

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.

I get it now. This explains -to me- why it seems to be easier to work
with QNX as opposed to Linux (I guess that I am somewhat biased, of
course, since I have very limited experience with Linux and years of
experience with QNX). However, what would you consider is the reason
behind the perception that more newbies would rather embark in the Linux
boat as opposed to the QNX one? I say this from experience: just about
every researcher (students and professionals alike) working on my side
uses Linux and resists QNX even though they are relatively newcomers to
the RT world. Legacy code/experience?

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?

I wouldn’t say so, but some people would argue that ‘real-time’ could be
defined on a rather arbitrary basis. Whence is hard to argue with them
that embedded Linux is not an RTOS, and because of this, you may be
perceived as confrontational.

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.

Is WinCE along this line?

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…

I get it now. Thanks.

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. I appreciate your input.

Bests…

Miguel.

\

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/

[Igor_Kovalenko2]

“Miguel Simon” <simon@ou.edu> wrote in message
news:3B00926A.5CC012F9@ou.edu…
…

I get it now. This explains -to me- why it seems to be easier to work
with QNX as opposed to Linux (I guess that I am somewhat biased, of
course, since I have very limited experience with Linux and years of
experience with QNX). However, what would you consider is the reason
behind the perception that more newbies would rather embark in the Linux
boat as opposed to the QNX one? I say this from experience: just about
every researcher (students and professionals alike) working on my side
uses Linux and resists QNX even though they are relatively newcomers to
the RT world. Legacy code/experience?

If they have previous Linux experience, sure it matters. If they don’t then
it is ‘flock effect’. Everyone likes to stay with ‘mainline’ and follow the
flock. Such approach has many non-technical advantages. Nobody will blame
you for your choice because it is ‘everyone’s choice’. You don’t have to
prove or ‘sell’ anything to your management - magazines do that. Magazines
also keep reminding you how great your choice is, for people with lack of
self-confidence it is important just like for women to keep hearing how
loved they are. Finally, if the flock goes wrong way then it is flock to
blame, not you personally.

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.”

Reading the article I got impression that author’s understanding of OS
concepts developed largely along the lines of his DOS-Linux transition. So
he jumps to conclusions here and there being under assumption that Linux
problems wrt realtime are generic OS problems (which is not true).
Nevertheless, here is another quote from that article:

• quote -
  “If you’re writing a device driver instead of working with one that ships
  with the data-acq hardware, it’s also important to realize that a real-time
  Linux driver must follow more strict limitations then a Linux driver. For
  instance, when a real-time task makes a call, the driver shouldn’t do any of
  the following:
  
  
  a… Allocate or free memory
  b… Use printk() or similar I/O routines
  c… Make blocking calls
  d… Copy data to or from the user space or somehow invoke the VMM (virtual
  memory manager)
  e… Use spinlocks or other synchronization objects between real-time code
  and Linux kernel
  Obviously, the behavior of a real-time driver should be deterministic.
  Recall that real-time Linux treats the Linux kernel as the lowest priority
  task. When your real-time task receives control, Linux itself can be in an
  unpredictable state such as in the middle of a spinlock or interrupt
  handler. Thus, you can’t rely on Linux services.”

• end of quote -

Nice indeed. What you can do then except for banging ports directly? Sounds
like you need to do everything inside interrupt handler. You might be on
time with first interrupt but what if they come too fast for your handler to
complete? Hmm, I forgot they are probably disabled at all while you are
there…

Basically, with that dual approach you are stuck with a primitive executive.
That won’t ever change because there’s no point extending its functionality
beyond some level, or why would you need Linux in the first place.

Note, there are somewhat different ‘dual’ approaches. Look at L4-based
systems for example. They are pretty much realtime microkernels running
Linux as a ‘server’. Difference is, they were designed as realtime
microkernels in the first place and only then started to run Linux on top,
whereas RTLinux and RTAI are just hacked Linux. So they are less primitive
but still not quite full POSIX.

Full POSIX+realtime is very hard thing to do because POSIX demands some
functionality which really takes LOT of efforts/experience to implement
without screwing determinism totally. Notice how that author suggests that
may be putting ‘preemption points’ into kernel would make it more
deterministic. What a great idea. QNX kernel is fully preemptable, all
system calls can be preempted at any point even in a middle of message
passing. Interrupts are disabled only for few opcodes and can actually be
nested. Interrupt handlers are very short because most of work is done by
drivers on user level. Actually you can have no interrupt handlers at all
under QNX6 (by attaching events instead of functions).

Note, some classic Unix systems, notably SunOS5 allow you to do that too
although with larger (but still more or less deterministic) latencies and
they have realtime schedulers as well. So, if I wanted just soft realtime
with a mainline OS in not-so-constrained environment I’d use Solaris rather
than Linux/RTLinux/RTAI.

If you want more insights you might want to read the famous ‘Linux is
obsolete’ thread, which is discussion between Linus and his teacher (I
believe Tannenbaum is his name) who wrote Minix (long before). In short, the
teacher was rather disappointed by stone-age monolithic design of Linux
kernel and went as far as saying that Linus would not pass his exams with
work like that…

• Igor

[Rennie_Allen2]

I get it now. This explains -to me- why it seems to be easier to work
with QNX as opposed to Linux (I guess that I am somewhat biased, of

course, since I have very limited experience with Linux and years of
experience with QNX). However, what would you consider is the reason
behind the perception that more newbies would rather embark in the Linux
boat as opposed to the QNX one? I say this from experience: just about
every researcher (students and professionals alike) working on my side
uses Linux and resists QNX even though they are relatively newcomers to
the RT world. Legacy code/experience?

Fear of something new ? The experience thing is probably due more to
lack of real-time experience than it is lack of Posix experience (if
they are Linux hacks). You simply have to point out to them that all of
the things that are “different” about QNX are there to support
real-time, and fault tolerance, and that this is what needs to be
learned whether using RTLinux or QNX (it’s just easier with QNX since
real-time/fault tolerance is designed in).

I wouldn’t say so, but some people would argue that ‘real-time’ could
be

defined on a rather arbitrary basis. Whence is hard to argue with them
that embedded Linux is not an RTOS, and because of this, you may be
perceived as confrontational.

You can’t argue with people who feel that determinism is arbitrary (buy
them a dictionary .

[Chris_McKillop1]

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:

You need to struggle harder. The 2.1 is not backward compatible to 2.0.
Worse yet, some applications from 2.0 would execute on 2.1 without
crashing but behave incorrectly, so they are not even 100% upward
compatible. And I suppose Andrew would complain he must rebuild Lisp
every time minor revision changes or it will crash…

No, I realize that 2.1 is not backward to 2.0 - but that is okay in my
books. I am sure other people’s books aren’t the same as mine though.
And you would have to bring up the whole “lets run a core dump” issue
with emacs eh? What a totally crazy concept to begin with! That is
why sane people use vi*.

chris

• • this thread will now die as it has mentioned both vi and emacs.

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[David_Hawley]

Miguel Simon wrote in qdn.public.qnxrtp.advocacy:

Dean …

Thanks. I get a better picture now. If I hear you correctly,
your point is in part that writing/debugging drivers will have
to be done regardless, and doing this from a user space is by
far a better option as opposed to doing the same thing from the
kernel space. This is a fundamental point I think; I appreciate
it. Thus we could argue that the lack of wide driver availability
for QNX is not as important as the fact that available
Linux drivers do operate in the kernel space, and that
the later is the greater of the two evils.

For many real-time applications, you are going to have to
write drivers regardless of how popular your OS is.

Driver development under QNX/Nto is going to be a lot
easier and quicker to do because you are just writing another
standard C/C++ program, using the same debugger and toolset
as your non-driver code. Since the driver is a standard process
you will tend to find that you have to reboot to OS far less
often which greatly speed up the Code, Compile, debug (!reboot)
cycle.

–
David L. Hawley D.L. Hawley and Associates

[Igor_Kovalenko2]

“David Hawley” <David.L.Hawley@computer.org> wrote in message
news:Voyager.010514215702.725010A@shadow.hawley.com…

Miguel Simon wrote in qdn.public.qnxrtp.advocacy:

Dean …

Thanks. I get a better picture now. If I hear you correctly,
your point is in part that writing/debugging drivers will have
to be done regardless, and doing this from a user space is by
far a better option as opposed to doing the same thing from the
kernel space. This is a fundamental point I think; I appreciate
it. Thus we could argue that the lack of wide driver availability
for QNX is not as important as the fact that available
Linux drivers do operate in the kernel space, and that
the later is the greater of the two evils.

For many real-time applications, you are going to have to
write drivers regardless of how popular your OS is.

Driver development under QNX/Nto is going to be a lot
easier and quicker to do because you are just writing another
standard C/C++ program, using the same debugger and toolset
as your non-driver code. Since the driver is a standard process
you will tend to find that you have to reboot to OS far less
often which greatly speed up the Code, Compile, debug (!reboot)
cycle.

One important thing that people miss is, it is not just debugging easyness.
Since drivers can be mostly/completely user space programs they don’t have
any restrictions typically being imposed on kernel space code. So it is
actually easier to design and code.

Another reality is development/testing cycle. Those can be very long and
changing any major part of product would require full re-testing to ensure
quality, at least in companies following SEI standards. In our case it means
new stuff must pass 3 different testing groups (developers tests, QA tests,
customer on-site tests) and it takes long time because each group of tests
has to simulate high load during long enough time. That means we must sumbit
new stuff for testing few months before deadline and we can’t resubmit it
every week as problems arise since testers time/capacity is limited and
every version would have to be tested from scratch… Then if we miss
delivery dates or stuff breaks after testing there are finance charges…
So, nobody wants to even think about introducing major disturbances like new
kernel versions.

In that reality it is very nice to have system where kernel hardly ever
changes, no matter how much new functionality you add. Look at USB support -
QNX added it without even touching kernel/process manager. Most other OSes
required major kernel surgery for that.

• Igor

[Igor_Kovalenko2]

“Chris McKillop” <cdm@qnx.com> wrote in message
news:9dq9ht$qvn$1@nntp.qnx.com…

Igor Kovalenko <> Igor.Kovalenko@motorola.com> > wrote:

You need to struggle harder. The 2.1 is not backward compatible to 2.0.
Worse yet, some applications from 2.0 would execute on 2.1 without
crashing but behave incorrectly, so they are not even 100% upward
compatible. And I suppose Andrew would complain he must rebuild Lisp
every time minor revision changes or it will crash…


No, I realize that 2.1 is not backward to 2.0 - but that is okay in my
books. I am sure other people’s books aren’t the same as mine though. >
And you would have to bring up the whole “lets run a core dump” issue
with emacs eh?

Not only that. I had a little proggie which did some devctl() to get
removable device status. Binary compiled for 2.0 would run on 2.1 but fill
in zeroes into status. QNX said ‘hmmmmmmm …’.

What a totally crazy concept to begin with! That is
why sane people use vi*.

chris

• • this thread will now die as it has mentioned both vi and emacs. >

–

cdm@qnx.com > “The faster I go, the behinder I get.”
Chris McKillop – Lewis Carroll –
Software Engineer, QSSL

[Dean_Douthat1]

Miguel Simon wrote:

Dean…

Dean Douthat wrote:

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.

Thanks. I get a better picture now. If I hear you correctly, your point
is in part that writing/debugging drivers will have to be done
regardless, and doing this from a user space is by far a better option
as opposed to doing the same thing from the kernel space. This is a
fundamental point I think; I appreciate it. Thus we could argue that the
lack of wide driver availability for QNX is not as important as the fact
that available Linux drivers do operate in the kernel space, and that
the later is the greater of the two evils.

Yes, but also, the existing Linux (Win32) drivers are not useful from the realtime side
not so much because they are in the kernel but because they are in a monolithic kernel,
therefore, they inherit its poor worst-case performance. Desktop OSs are optimized for
average case performance; by stuffing more and more into the kernel. To get good
worst-cast performance, take everything you can out of the kernel; that is, make it a
micro-kernel (or exec). And, of course, make what little remains pre-emptable.

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.

I get it now. This explains -to me- why it seems to be easier to work
with QNX as opposed to Linux (I guess that I am somewhat biased, of
course, since I have very limited experience with Linux and years of
experience with QNX). However, what would you consider is the reason
behind the perception that more newbies would rather embark in the Linux
boat as opposed to the QNX one? I say this from experience: just about
every researcher (students and professionals alike) working on my side
uses Linux and resists QNX even though they are relatively newcomers to
the RT world. Legacy code/experience?

Baby duck syndrome, perhaps. What they were first exposed to in school, etc. Imprinting
and all that.

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?

I wouldn’t say so, but some people would argue that ‘real-time’ could be
defined on a rather arbitrary basis. Whence is hard to argue with them
that embedded Linux is not an RTOS, and because of this, you may be
perceived as confrontational.

Humpty Dumpty approach to defining words is a great advantage in any argument.

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.

Is WinCE along this line?

No

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…

I get it now. Thanks. >

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. I appreciate your input.

Bests…

Miguel.

---

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/

[Miguel_Simon1]

Dean…

Dean Douthat wrote:

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.

Thanks. I get a better picture now. If I hear you correctly, your point
is in part that writing/debugging drivers will have to be done
regardless, and doing this from a user space is by far a better option
as opposed to doing the same thing from the kernel space. This is a
fundamental point I think; I appreciate it. Thus we could argue that the
lack of wide driver availability for QNX is not as important as the fact
that available Linux drivers do operate in the kernel space, and that
the later is the greater of the two evils.

Yes, but also, the existing Linux (Win32) drivers are not useful from the realtime side
not so much because they are in the kernel but because they are in a monolithic kernel,
therefore, they inherit its poor worst-case performance. Desktop OSs are optimized for
average case performance; by stuffing more and more into the kernel. To get good
worst-cast performance, take everything you can out of the kernel; that is, make it a
micro-kernel (or exec). And, of course, make what little remains pre-emptable.

Thanks. I am summarizing all of this, then I’ll put what the summary in
the news group with the appropriate credits. You do not mind if I use
your comments, do you?

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?

I wouldn’t say so, but some people would argue that ‘real-time’ could be
defined on a rather arbitrary basis. Whence is hard to argue with them
that embedded Linux is not an RTOS, and because of this, you may be
perceived as confrontational.


Humpty Dumpty approach to defining words is a great advantage in any argument.

Yup. However, with the document that I am preparing I’ll define my
position from a strictly technical point of view. It is always
frustrating when the decision makers opt to behave as blind and depth
people. This attitude toward technical reasoning always reminds me of
the Challenger disaster, and regardless of what any one says, culture
does have a big impact on the use or misuse or under use (?) of
technology. But enough philosophy.

Thanks for your help… I appreciate it.

Bests…

M.

\

my opinions are mine, only mine, solely mine, and they are not related
in any possible way to the institution(s) in which I study and work.

Miguel Simon
Research Engineer
School of Aerospace and Mechanical Engineering
University of Oklahoma
http://www.amerobotics.ou.edu/