Hello,
I'm working on porting an application from QNX to Linux as part of some work for Cisco, and I as well as other team members are having issues resolving QNX -> Linux dependencies.
I was wondering if there was a list of analogs for QNX kernel items in the POSIX / Unix world, in particular the QNX dispatch manager and devctl.
Thanks,
-Garrett
There is no analog in Posix, or in historical Unix, for MsgReceive (which is what the “QNX dispatch manager” actually is underneath). QNX is a microkernel, and as such the entire O/S, as well as user applications (which includes drivers) are client/server based, built around the inherently synchronous message passing model of a microkernel.
I could explain in detail how this all works, but what could be better than downloading the source yourself and finding out?
QNX is far more advanced operating system than Linux, so (as can be expected) porting back to a less sophisticated model may be difficult (going forward, is always easier than going backward).
FYI: The entire O/S source base is available at community.qnx.com/sf/scm/do/list … ore_os/scm
I understand the fact that QNX is a microkernel based OS, and while I agree that it’s most likely a more complicated model, it would be nice if some things were cross-OS compatible to some extent.
Then again what I’m asking for is most likely at the syscall level, which means that I’m not going to get a working reply anytime soon, for good reason.
I suppose the best source to hit up is the Msg* sections of the manual as well as the kernel dev guide?
Thanks,
-Garrett
Actually, I’d characterize a micro kernel as a simpler model than a monolithic kernel (I generally equate “advanced” with simplicity, since it is my experience that the better we understand a problem domain, the simpler and more elegant the solutions we invent). While a micro kernel is simpler, it is a fundamentally different architecture that a monolithic design. Micro kernels appeared long after mono kernels, so one of the design constraints was that they had to be compatible with porting application code from mono kernels, while the reverse was (obviously) not true; hence my statement that porting backward is harder…
More than “some things” are compatible, there are some 1300 interfaces in Posix. QNX is a Posix certified OS (get.posixcertified.ieee.org/disp … cp_id=6693), so Posix applications are 100% portable to/from QNX and any other Posix compliant operating system (unfortunately, Linux is not Posix certified, so while it is highly compatible, it isn’t quite 100%).
In effect, you are asking about O/S extensions (this is what the dispatch interface is for). So I guess what you would like are portable operating system services (which Posix doesn’t address).
Portability of operating system services is a pretty weird concept actually. If O/S services could be ported between operating systems, there would be little room for innovation (i.e. all operating systems would essentially have the same architecture). Posix explicitly stays away from any suggestions about the implementation underlying the interface , precisely so that innovation is preserved.
I think your saying the same thing here as my statement above (regarding portable O/S services).
The Msg* sections of the manual describe the interface (not the implementation). I am not aware of a kernel dev guide, but if you know of one I’d love to get my hands on a copy 
I think the source code (from Foundry27) is the best reference. Keep in mind though that there are some software patents involved (specifically the mechanism by which IPC is distributed across a communication medium).
It is certainly possible (not even that difficult) to implement MsgSend/Receive in Linux (someone did it once for QNX4 IPC), but it would be quite a trick to achieve performance even remotely similar to that exhibited by QNX (without essentially modifying the Linux kernel to the point where it would effectively become QNX). If you read the kernel source you’ll see why…
Why are you porting from QNX to Linux anyway? Just curious
The Send/Receive/Reply implementation that you are referring to is probably “Simpl”. It was ported to QNX 4, and it internally implemented its message passing interface over QNX 4 message passing, but the external message passing ran over TCP/IP sockets. A couple of years ago I recompiled the generic version of Simpl to QNX 6, and did so without much effort. This version implements all message passing over TCP/IP.
Simpl seems to have found its place as a “nice” way to move data between foreign OS’s, although there are obviously others.
I’m not sure if I understand your comment about portable operating interfaces. Isn’t one man’s syscall another man’s interface? In other words, is there some syscall in Linux that would be impossible to simulate under QNX, and vise versa? Of course I agree that portability does not mean equivalent performance.
I am referring to SRR (developers.cogentrts.com/srr/README.html) written by Sam Roberts and Andrew Thomas.
It is not impossible to implement a QNX syscall in linux (or vise-versa). In most cases it isn’t even difficult to get something that works.
Even the equivalent performance can be obtained, but as I said in my earlier response, it might entail restructuring the target O/S so radically, that it (for all practical purposes) becomes the O/S that the service is coming from; which then begs the question… why?
Never underestimate the ability of a large disfunctional organization to make life impossible for a programmer, for no real reason.
Years ago I did some work for a uh, large well known company that was very “Blue”. They only relented to using QNX because the alternative, MSDOS, would not work at all for what they required. The first implementation on an original IBM 8088 PC outperformed the Series 1 that it was replacing. That was in spite of the fact that Series 1 had separate processors for its I/O. After many years of finding QNX an exceptionally performing product, they would still on a yearly basis re-evaluate whether they could accomplish what they wanted to do on a Microsoft product.
I’m quite sure that if they could figure out a way to port the QNX system calls to MSDOS, they would have.
Didn’t try to do it with OS2
Well, for a good bit of time it was one of the options, but of course it didn’t work very well either.
You’re kidding, right? “Well son, I could tell you how gasoline and air are compressed together and then ignited to make the engine work, but instead why you don’t get $5,000 worth of tools, a lift, a jib crane, and 10,000 pages of documentation, then spend the next 18 months taking the engine apart, even though you’ll probably have no idea what in the hell you’re looking at.”
I’ve always had this complaint about open source software. “You can look at the code, and even make changes yourself!” Gee, thanks. There are what, 12 people on the planet that can so much as correct a spelling mistake in a comment in the Linux kernel? Hell, the LAST thing I want from QNX is to look at the source code. If I could understand code at that level I’d be selling my own RTOS! I’d go so far as to say that the entire point of buying a commercial RTOS is to make sure I don’t ever have to look at system-level code.
Well, I don’t know why yaneurabeya is doing it, but I’ll tell you why I would. Let’s start with no way to display any form of vector drawing, period. No .dxf, .ai, .svg, or even .pdf. No Flash. Oh, wait. There IS Flash; that’ll be $10,000 please. No Java. Oh, wait. There IS Java; that’ll be FIFTY THOUSAND dollars please. (No, I am NOT making that number up.) GCC, but only C and C++; no gcj, Objective-C, Fortran, or Ada. Oh, and the version of gcc is out of date, with no TR1 stuff. And maybe if you’re lucky you can get the Boost libraries to compile. God forbid you want a compiler OTHER than gcc. (Okay, okay, you can in fact buy the Intel compiler now. That’s two I can chose from!) QNX Message Passing is great… except it doesn’t extend to objects. Can’t send a C++ STL string with MsgSend, much less a user-defined object. Same problem with Photon; great little GUI, but no C++ (or other object-based) interface. Subversion works, but there’s no GUI. The only available IDE is Eclipse… which is an additional $4,000. Unless you have Java already, which was $50K. No Eclipse? There is exacly one text editor available, and it does not have an undo function. Let me say that again; THE QNX TEXT EDITOR DOES NOT HAVE AN UNDO FUNCTION!!! Did I mention that there is no way to display a PDF? No GTK, no Qt. Oh, wait. There IS GTK and Qt, once you’ve installed the hundreds of megabytes of X11, then emulate X, slowing any X / GTK / Qt applications to roughly that of pouring molasses in Alaska, assuming they work at all. I mentioned a few weeks back on openQNX that I went 10 years without being able to get a touchscreen monitor to work.
If I were doing an embedded programming project today I would pick Linux. We still support our old QNX (4 and 6) systems, and we even sell one or two new systems a year, always to customers that already have some of our systems. We haven’t bothered porting our old stuff to Linux though. We switched to using Programmable Logic Controllers, because that’s all that our customers in the industrial automation world would accept.
Sorry about the rant. I’m at a job site in Mexico. I’m tired, cranky, hot, sweaty, stinky, and on a painfully slow Internet connection.
-James Ingraham
I’m glad you explained your environmental situation, we’ve all been in uh, sticky situations, otherwise I’d have read your comments as just another Unix purist flame. There’s a long history of this. For years I would hear that QNX was no good because it wasn’t UNIX, and this was long before UNIX could run in any meaningful way on an Intel processor.
So I think it is worth putting into perspective what QNX and Linux are. I think they are both wonderful OS’s, but very different at many levels. Linux is an open source, public domain OS used world wide by hundreds of thousands, maybe millions of users, hackers, and businesses. It is a startling success. It has been guided along by some dominant figures, but not controlled, so it was free to evolve in a organic way.
QNX has always been a proprietary product. That they will let you see and even modify their code now, does not change this. QNX was built with different design goals. It was built to have a very small foot print, provide real time capabilities, and only in its latest incarnation has it been so specifically targeted at the embedded market. Its ability to self host, should indicate its original general purpose nature. QNX side-cared onto the abundant UNIX/Linux open source bazaare by providing POSIX conformance. Sometimes porting is still not straight forward. I’ve been trying to get the latest Apache 2 working for quite a while. Posix conformance is not the same as being UNIX or Linux compatible.
Some of your complaints about things lacking in QNX were address by providing a cross development system. If you want to display a PDF, go ahead but do it on Linux or Windows. You want to display a PDF on an embedded QNX system? Well I have no answer for that. You are right. Not every format that would be usefull, nor every neat widget, gizmo, or thingamajig is available for QNX. A company of 200 is no match for the Linux world. Want to compile Fortran on QNX? You are trying to use pruning shears to give someone a hair cut.
Message passing won’t pass objects? Neither do pipes. Is that a failure of pipes? You seem very troubled by the editors available. Well there is definitely more than one editor available, but I’m sure that you will like qed much less than ped, so lets not get into it. With qed and ped there is an undo, but it’s not very elegant. Quit without saving. I know it’s probably because I grew up during the dark ages, but it has never bothered me that I didn’t have a new fangled fancy undo. But if it does bother you, then you can cross develop and use any Windows editor that you like.
I think you might have the same reaction if I said that Linux stinks because it is not natively real time, or that drivers won’t dynamically restart if they crash.
No offense taken of course. I’d like to see all the things you mention available under QNX too.
The editor ws ( workspace ) is not bad.
It seems QNX6 was targeted to be the elusive “Holy Grail” of operating systems, scaleable from the small embedded systems up to the largest distributed network. Somewhere along the line they decided to focus on fortune 500 business and gave up the Holy Grail effort. Desktop folks don’t want to give up the tools they know and love and embedded folks want to keep the bloat out (meaning STL and often C++ entirely). So, they had a choice to make.
Linux supports most of the stuff you’re asking for, and if that’s what you want and/or need your choice is made.
QNX meets my projects need, and usually much better than the alternatives. I do wish the tools were better (especially editors) and eclipse drives me nuts. It’s really too bad the enthusiastic QNX user community is mostly gone - if it were still intact some of the missing features would have been available by now.
To further clarify: I’ve used QNX for my entire 10 year career as a developer of industrial automation software. I think it’s got some great stuff. I think the microkernel architecture is brilliant, and Torvalds is being pig-headed when he says “microkernels sux0r!” QNX Message Passing is the most elegant interprocess communication system I’ve ever seen.
I used SunOS and Linux (0.9x!) in college, and Solaris a little in my first job. I’ve played with Linux occaissionally, but never used it seriously. I have never done any commercial work with Linux.
I have no problem with this. Richard Stallman is a lunatic.
That QNX self hosts is the primary reason we never seriously considered moving to another RTOS. Our systems are “embeded,” but only in the sense that the computer they run isn’t doing anything besides our apps. Our industrial machines sell for upwards of $100,000, so adding a couple gigs of RAM or cranking the processor speed has never been an issue. What we DO need is the ability to recompile our applications on the machine itself. Every machine we build is a one-off. If the customer finds a bug or requests a change we don’t want to have to pull out a development system, make sure it’s got the right versions of our middleware and the customer’s app, do everything offline, then transfer over. That makes sense if you development once deploy many. We develop once, deploy ONCE.
Again, we want our customers to be able to pull up a document (for example an electrical schematic) at the machine. I talked to QNX about it; they said that they don’t have a single customer anywhere in the world who has even THOUGHT about displaying a PDF. Which I find nearly impossible to believe.
Of course, I don’t need EVERY whiz-bang gizmo. But there are some that give you more bang for your buck than others. A Photon-native port of GTK+, for example, would solve a lot. You’d get editors galore, and PDF viewing! Boost is another. At this point, Boost is damn near part of the C++ standard. You’d get a LOT of features by making sure Boost worked on QNX.
Actually, I think Objective-C makes less sense than Fortran. Fortran is at least an engineering language. And Ada ABSOLUTELY makes sense on QNX. In fact, you can go buy it for some obscene licensing fee from Aonix. And on the “bang-for-the-buck” front, how much harder is it really to keep the entire GNU Compiler Collection working instead of just the C and C++ compilers?
No, it’s not a failure of pipes. It’s not a “failure” of message passing, either. However, pipes are one tool that is used. Sockets is another. (Still no objects.) However, QNX message passing is so fundamental to the system that you pretty well MUST use it. So it would be nice if it could handle objects. The crazy thing here is that if I could use Boost then message passing would supports objects through serialization! QSSL has big press releases on all their cool stuff; why not get Boost working and rave about how they have an object-oriented embedded interprocess comunication framework (and other buzzwords) that is ten times faster than CORBA and a hundred times easier? They’d barely even have to do any work! Just a little time making sure Boost stays working on QNX.
Perhaps I should have said “Photon,” rather than QNX. But even then qed is deprecated, and evlis is, well… vi.
Okay, that doesn’t count.
I’m not sure when you mean by “dark ages,” but emacs in terminal mode on SunOS in 1992 had undo. So did VEDIT when I started using it in QNX4 in 1997. I have trouble remembering farther back than that, so I don’t know if the Turbo Pascal and Turbo C “IDE” had undo, but I know WordPerfect 5.1 did. So I’m not going to count undo as “new-fangled.”
Also, I actually wrote a text editor in Java so we could use it in QNX. And then from 6.2.1 to 6.3 QSSL ripped Java out from under me.
As I mentioned above that’s not really an option for us.
Not exactly the same reaction. I could certainly go off on Linux’s failings, but I have a lot less experience with it. I admit I’m very hard to please. I frequently rant at my vendors, and then they’ll say something like, “Well, who in the industry DOES do it the way you want.” And I always have to answer, “Nobody, damn it!” I can’t figure out if no one does the things I want because I’m so brilliant that only I can think of them or that it’s because I’m so incredibly stupid nobody even wastes a single neuron firing over such a bad idea.
Oh, and Linux is now natively real-time, for whatever that’s worth.
I’m glad. I’m aware I often come off as an obnoxious snob. I’m just don’t know how to stop it.
-James Ingraham
Tried it. Its last release was in January of 2003, and it was never officially out of beta. “Not bad” I agree with, but it’s a not exactly good, either.
-James Ingraham
Okay, that doesn’t count.
It may not count, but it does work.
I started in 1974 with a TTY terminal that ran a basic interpreter, and we saved programs to paper tape. The editor in basic was simple. Type a line number and a line. Make a mistake? Type the line number again and retype the line. When entering programs off-line to the paper tape, you pressed a button on the tape punch to backup on character, and then you pressed rubout to erase it. That’s what backspace was.
My next programming experience used IBM cards. Make a mistake? Throw away the card and retype.
In 1977 I used a system called Wilbur on an IBM Mainframe which was the nicest line editor I’ve ever used, but no undo.
Finally in 1978 I ran into my first full screen editor that ran under IBM’s TSO/MVS called SPF. 3270 terminals seem very archaic by today’s standards. You pressed enter to send whatever was on the screen to the computer, and then you waited for the return. A nicer later editor was XEDIT, which had a short life on PC’s as KEDIT. None of these had an undo.
That’s what I mean by the dark ages.
I also had some brief but interesting experiences with an IMSI, an Altair, and an IBM mainframe in which data was entered directly into memory via binary switches. I think there’s one of those “real programmers …” jokes here. Real programmers write in machine code, and enter their data directly to memory. Yahoo .
I’ll believe it when I see it.
I have to say, I’m glad you are pushing for all this stuff. Somebody has to, and I think it’s past my time. I used to see gaps in what was available for QNX as opportunities. Open source has pretty much removed this incentive. If companies wanted to hire someone to make some package work on QNX, they could hire me but there doesn’t seem to be much interest in this.
Eclipse is free. You can’t compile from it but you can use it has an editor no problem.
As I mentioned above that’s not really an option for us.
We added a windows machine to our system to solve that problem 
In fact we moved all of our GUI to windows. If you sell a machine 100 000k one PC won’t make that big of a difference.
Ah, well there’s free and then there’s “free.” We bought QNX Momentics Standard Edition. It does not come with Eclipse. No big deal; I can download it from eclipse.org, right? Except that Java is a requirement. And while 6.2.1 came with j9, 6.3.x does not include Java support in Standard Edition. I have to upgrade to Professional edition. For something like four grand. Or spend fifty grand for an alternate Java solution. Which would be fine if I shipped 1,000 systems a month, but I ship ONE a month. And since we’ve mostly switched to PLCs anyway, I’m down to one or two QNX runtimes a YEAR.
That leads to having a second failure point, and the added complexity of communicating from Windows to QNX, and dual-training all of my programmers for QNX and Windows development, and extra debug time to find out which side of the system is screwing up, and I can’t stand having Windows on the factory floor. Not because it isn’t relaible enough; I have quite a few Windows systems out there ruuning real machines on real factory floors. It’s because when the hardware fails I can’t just send the customer a drive pre-configured to get them up and running. Windows gets really cranky if you move a hard drive from one machine to another, and that’s to say nothing of the problem of patches. We’ve got computers out there running QNX 4.22 and Photon 1.0 BETA, and right now I can ship a hard drive that will work. If I need a Windows drive I have to start an install from scracth on the actual hardware I’m going to leave it on. Plus the hassle of activation.
Here’s the question; if QNX doesn’t work well for self-hosting, exactly what advantage does it have over other RTOSes? Message passing? OSE. Market share? VxWorks. Cost? Linux. Scalability? velOSity or ThreadX. Safety and reliability? INTEGRITY. Maintaining developer training when switching from Windows? Windows CE.
There’s exactly ONE thing QNX has that the other’s don’t. And that’s a compiler. (Well, Linux obviously also has the compiler.) So if I don’t self-host then what’s the point of QNX?
-James Ingraham