Comment by Animats | Hacker News Reader

Comment by Animats | Hacker News Reader

Parent Full thread

Probably never.

Trying to emulate Mach, which was a dud as a microkernel, didn't help.

QNX is one of the few microkernels to get it right. L4 got stripped down so far that it's just a hypervisor, on which people usually load Linux. L4 took out arbitrary-length message passing in favor of interrupt-like events and shared memory between sender and receiver. This simplifies the kernel, but now it's easier for one side of a sender/receiver to mess up the other, since they share a communications area. The QNX primitive set (MsgSend, MsgReceive, and MsgReply) work well enough in practice to allow full POSIX functionality. Applications can talk to file system servers, network servers, etc. through those primitives. All QNX I/O works that way. You take maybe a 20% performance hit for the extra copying, but you get robustness in exchange.

Most important thing for performance in a microkernel: the CPU dispatcher and the message passing have to be tightly coordinated. You must be able to call another process and get a reply back without trips through the scheduler or a switch to a different CPU. QNX gets this right, because MsgSend is blocking. The sender blocks and the receiver starts without having to schedule. The data being sent is right there in the cache of the CPU, ready for use by the receiver. Good test for a microkernel - put some CPU-intensive jobs in a loop, while also running something that makes short request/reply calls to another process. If the request/reply process stalls out, the microkernel is doing it wrong. If the CPU-bound processes stall out, the microkernel is doing it wrong. Message passing should schedule as smoothly as a subroutine call. If it doesn't, performance under load will suck.

Arrrrrgh.

Roar.

QNX was cautiously courting the open source concept and venturing in the direction of shared source (with some code already available), when BlackBerry bought them and threw all of that out the window.

Biggest yanked opportunity. D:

Now QNX is all-commercial again, with source only available under a license. And Photon is gone, too: no more self-hosting.

I wish BB would(/could?) do the webOS thing with QNX. That would be amazing. The community would absolutely get Photon up and running again, it would be an alternative to Linux and BSD.

data:text/html;base64,SSBmaWd1cmVkIG91dCBob3cgdG8gZ2V0IFFOWCA0IGxpY2Vuc2VkIGEgd2 hpbGUgYmFjay4gSWYgeW91IGdldCBzdHVjayBteSBlbWFpbCBpcyBpbiBteSBwcm9maWxlLiBJZiB hbnlvbmUga25vd3MgaG93IHRvIGxpY2Vuc2UgNi54IEkgZG93bmxvYWRlZCB0aGF0IHRvby4=

I know. QNX the OS was great. QNX the company has been a huge pain to deal with for more than a decade. They had a tough problem, though. Who else sold a desktop OS for real money any more? Unlike Microsoft and Apple, they had no other revenue stream. Still, until about 2005, QNX was considered a target which UNIX-like software should support. There was an early version of Firefox (called Firebird) for it, all the command-line GNU tools were available, and the Eclipse IDE worked fine. For three years, while I was working on a DARPA Grand Challenge vehicle, I ran QNX on the desktop.

Photon, the GUI, probably had the sanest internals of any major GUI system.

Dan Dodge, who designed much of QNX, was CEO of QNX, and he retired from QNX/Blackberry to go work for Apple. Apple might end up doing something in this direction. But if they do, they'll never let the internals out.

I'm curious what was wrong with QNX the company, in terms of the practical ramifications of what you're describing.

I assume you were using QNX for the GC vehicle compo because of its RTOS qualities? In any case, that's awesome.

I thought Photon was pretty cool too, at least from a "oh hey these screenshots look awesome" perspective. I vaguely recall running it in a VM, once, so long ago I only hazily remember poking around the sidebar. Sadly it'll be somewhat challenging to do further academic research on that subject now, I wish the educational/noncommercial free options still existed there.

Also, I found (and bookmarked) this HN thread from some time ago that's got some QNX gems in it: https://news.ycombinator.com/item?id=4834334 (very curious about the modem)

And you're very sadly right about Apple, they're very unlikely to release the truly interesting bits of any projects like this.

Woops, typed text/html out of habit, meant text/plain. base64 -di works just fine too.

If anyone's looking for a student friendly version on microkernels and specifically Send/Receive/Reply, take a look at the resources for UWaterloo's CS452 here. [1]

That course features implementation of microkernels based on QNX from scratch to drive trains around a track, should be straightforward to implement on a Raspberri Pi or a Pandaboard/Beagleboard. The course uses a TS7200 which is an older ARM chip.

[1] http://www.cgl.uwaterloo.ca/wmcowan/teaching/cs452/w16/notes...

Back in the mid-90s I had some friends who worked at a company that sold commercial X-Window servers. Their fastest X server ran under QNX. That either says something about how fast QNX was, or just how bad Unix was at the time.

Reply on news.ycombinator.com