Running LINUX on QNX

Hello All,

Has anyone attempted to run Linux on QNX as a thread, like RTlinux does ?
Idea being you then have a good RTOS and have all the Linux applications. I searched and couldn’t find any info on this topic.
Any pointers or inputs is much appreciated.


Wouldn’t running a non-RTOS on a RTOS comprimise the part of the RTOS being RT when it comes to linux apps? Wouldn’t it be better to run a RT-Linux kernel rather to running Linux on QNX?

Dont think thats possible, although dont take my word for it :smiley: . As for “all” the linux apps, what exactly are you looking for? There are numerous sites that contain many recompiled or ported *nix apps packaged and ready to go for QNX. Wine, vmware and openoffice are out of the question, but most other *nix apps are quite doable on QNX. and’s links pages along with google searching for “qnx apps” “qnx ports” etc have all but satisfied my needs.

usriniva, I guess it’s possible, but I don’t see much potential for this kind of stuff.

Well, it may be possible but not the way RTLinux does it. RTLinux is a very simple executive that lets linux do the heavy lifting. While Neutrino is already doing the heavy lifting. Much easier to get something like lxrun working on Neutrino. Which has been done btw, by a QNX customer. So it is possible. :slight_smile:

Is running something on top of QNX to be able to run linux apps in RT efficient? I read that Linux 2.6.* kernel versions are not to far from operating in real-time them selves… Wouldn’t it be just as if not more efficient to do whatever you are doing on a linux kernel that will natively run your apps rather than running a special application on QNX to do so?


Thanks for all the replies!

Yes we could use RTlinux. Couple of sticky issues

  1. RTlinux patent linence
  2. GPL : we want to protect some part of the kernel code for an appliance.

Our code runs in kernel mode for performance so using LINUX directly we will have to open all our code under GPL.

I don’t understand all the issues clearly yet…

What we are trying to do is

  1. use commercial/opensource RTOS, run LINUX on that. This will get us access to all linux apps being developed.
  2. Since QNX (or another RTOS) is in control, LINUX running as a task cannot mess around with other RTOS apps running on QNX.
  3. we are hoping that by running our appliance code on top of QNX we won’t be bound by GPL.

Appreciate your inputs!

If you control which linux apps you will want to run, then you can either port them to QNX (which isn’t that hard in most cases) or run them under lxrun.

If you want to let the end user choose which apps to run, you will have a much larger issue - some apps have problems running under different versions of linux, never mind another os.

You are aware tho, that using linux (or QNX) as a GUI desktop environment will break your ability to do hard realtime, right? In particular if you have any devices on your machine which are bus mastering (video cards, for example).


Sounds like you should initiate the lxrun/QNX porting project and get those people who have worked on it in. Last I heard it was a tedious job to map all functions calls, but with the commercial backup you have, it will be possible.

I don’t think that you should be bound to the GPL by making a kernel module… when editing GPL code you are bound to make it public… as for your own kernel modules, I don’t think so.

(Would have to read through a GPL licence to be sure)

There is more out there then RTLinux…

I would give runlx under QNX a try though… then you can tell me if and how it is doing it’s job ;)

Have fun,


Here’s a link to to lxrun for QNX. Its pretty old–4 years since an update. … project=31

The 2.6 Linux kernel isn’t even close to being realtime. They have improved the worst-case numbers under 0 load to be under a milil-second, but if you put it under load the numbers actually get worse then if you didn’t have the pre-emption/low-latency patches. That is why the rt-linux stuff is so powerfull.

Getting lxrun to work isn’t too bad really, only a matter of getting some of the SysV stuff mapped.