Linked by Thom Holwerda on Wed 29th Sep 2010 19:07 UTC, submitted by poundsmack
QNX When Research In Motion unveiled its BlackBerry Playbook tablet on Monday, including the new QNX-based operating system it runs, I already speculated that it would probably make its way onto RIM's smartphones as well. RIM has now confirmed this suspicion.
Thread beginning with comment 443226
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: The triumph of UNIX
by moondevil on Thu 30th Sep 2010 11:01 UTC in reply to "RE[5]: The triumph of UNIX"
moondevil
Member since:
2005-07-08

They have lots of nice optimizations in place to allow quick communication between kernel modules.

I imagine that QNX is the only successful micro-kernel OS out there.

Reply Parent Score: 2

RE[7]: The triumph of UNIX
by talaf on Thu 30th Sep 2010 13:21 in reply to "RE[6]: The triumph of UNIX"
talaf Member since:
2008-11-19

VxWorks does quite well afaik and is a micro kernel too. Micro kernels in general are found in embedded computers anyway, because size and modularity are pretty key in that field.

Reply Parent Score: 1

RE[8]: The triumph of UNIX
by flyingrobots on Thu 30th Sep 2010 15:06 in reply to "RE[7]: The triumph of UNIX"
flyingrobots Member since:
2010-09-30

I don't believe VxWorks is a microkernel. My understanding is that device drivers do not run as separate processes but as threads in the VxWork's kernel. Thus no memory protection is offered to critical system functions. VxWork's kernel comprises of a bunch of non-os related stuff (tcp/ip stack, device drivers, file systems, etc, etc). It can get quite bloated.

It takes some very smart and knowledgeable people to make a VxWorks system run reliably. A lot of kernel level debugging is required when implementing new device drivers or other services that need to reside in kernel space. Much care has to be taken to insure that it works well.

QNX's kernel on the other hand only implements the very basic OS needs. Scheduling, memory management, timers, inter-process communications, and thread/process management are in the kernel.

That's it.

Network protocols (packet filtering, firewall, and other TCP/IP related features), device drivers, file systems and other hardware related software services run in user land.

When new device drivers are implemented, normal application debugging can take place. You can start and stop device drivers at will and unless you do something that causes the hardware to fail or work incorrectly, the system remains responsive in the face of a device driver failure (segfault for example). Also when you newly minted device driver faults, you get a core dump. Load that core dump in your debugger, you get a stack trace as well as variable values at the time of the crash. It's nice.

VxWorks kernel can be small in size, but size doesn't make it a microkernel. QNX's kernel, by the way, is very compact and does not change size with different system configurations.

I think QNX still stands as the only well implemented microkernel.

Reply Parent Score: 2

RE[7]: The triumph of UNIX
by Neolander on Thu 30th Sep 2010 14:08 in reply to "RE[6]: The triumph of UNIX"
Neolander Member since:
2010-03-08

They have lots of nice optimizations in place to allow quick communication between kernel modules.

I imagine that QNX is the only successful micro-kernel OS out there.

Not quite right. SymbianOS has some success around the world, too, and if I remember well it's based on a microkernel called EKA2...

Reply Parent Score: 2

RE[8]: The triumph of UNIX
by bogomipz on Thu 30th Sep 2010 15:46 in reply to "RE[7]: The triumph of UNIX"
bogomipz Member since:
2005-07-11

"I imagine that QNX is the only successful micro-kernel OS out there.

Not quite right. SymbianOS has some success around the world, too, and if I remember well it's based on a microkernel called EKA2...
"
Quite right, check out this article for an interesting read:

http://www.informit.com/articles/article.aspx?p=1578523

I especially noticed the following passing about fork():

If you write POSIX code on Symbian, you'll notice that it has no equivalent of fork(). This call on UNIX systems is a holdover from very old minicomputer architectures that didn't have protected memory. On a context switch, they would write the current process out and load another one in. When you created a new process, you got a copy of the old one for free. On modern UNIX systems, a huge amount of effort is made with copy-on-write hacks, to pretend that this is still the case. This history doesn't exist with Symbian, so it has no fork() analog. To create a new process, you specify a program binary and get a completely new process, not a copy of the old one.

Reply Parent Score: 2