- VxWorks (https://en.wikipedia.org/w/index.php?title=VxWorks&oldid=857...)
- Nucleus (https://en.wikipedia.org/w/index.php?title=Nucleus_RTOS&oldi...)
- perhaps ThreadX (the "spiritual successor of Nucleus") (https://en.wikipedia.org/w/index.php?title=ThreadX&oldid=852...)
are on this list.
"The 64-bit Linux infrastructure is the de facto standard that is being used across the industry today...So it gives us more development tools, more tool chains and also more access into the third party development ecosystem."
http://mobile.enterprisenetworkingplanet.com/netos/cisco-evo...
XR itself provides abstractions on top of QNX and Linux, so devs working on platform independent code are not really affected.
All data plane activity is done on custom in-house ASICs called network processors (NPs). The CPU only handles control plane traffic and general administration.
It did a few really cool things for its time, considering that TCP/IP networking was an optional add-on when we originally deployed.
When the code is not enough, I go to http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.qnxsdp...
There are plenty of changes to the userspace runtime, but the question was about the kernel.
Oh, also, 7.0 has an ISO 26262 certified variant. Not a technical difference, but an important one.
--
QNX was momentarily open for a little while until the license change with BlackBerry et al. My question: did this license change only apply to future QNX versions, or did it also retroactively apply to the "open"-sourced code as well?
My primary current interest in QNX stems from being fascinated with old and/or unusual operating systems. I'd love to be able to go fishing for 6.4 et al, maybe even compile what I find from source (or maybe not), and basically just play with the system to see how it works. If it's fine for me to go and find 6.4 and poke at it for noncommercial purposes - well, that'd be awesome to know. Obviously such a usage model would not incorporate any official agreement or warranty, and I understand that.
In a somewhat related vein, at some point I may find it useful to observe how QNX handles certain technical minutiae as part of my own (hopeful) OS development work. Obviously sourcing the latest versions of the QNX source for this purpose would offer support options, not to mention a more relevant codebase; but it would be great to know that I'd be able to safely make do with the older releases as long as I don't seek/expect any form of support.
--
I was unfortunately out of the loop with the QNX scene during the period it was open so I never got a chance to grab any of the repos. (And a quick search turned up what appears to be some QNX 6.4 bits and pieces on GitHub (as the previous comment hinted at) but it doesn't look very official, so I don't want to sift through it in case I waste my time.) Of course official repo access has since been closed, so I can't check that. So: I figure why not ask, what can it hurt.
When the repo was opened, did it include full commit history, or a large portion of it?
QNX 4.x is really cool. I managed to get an old copy working in a VM some time ago (took a bit of thinking; there's so little documentation out there). 6.x is nicer, but 4.x feels faster (which kind of makes sense).
--
I've been fascinated with QNX for years, and to be honest I want to say I find the "closed > yay open!! > closed" timeline incredibly frustrating; but besides wistfulness, this has also generated a fair bit of confusion regarding the current status quo.
They deprecated some POSIX calls like posix_spawn_file_actions_addopen (at least in QNX6.6 documentation they mention it's not fully implemented and it is indeed broken).
They made the QNX7.0 kernel instrumented-only (there are no longer non-instrumented versions).
They changed lots of low level stuff that is outside the kernel, like throwing out photon and replacing it with screen library, completely replacing the PCI server, making changes to the console, security patches, and so on. But since it's a microkernel, this is mostly in userland.
What is the most mainstream or perhaps "least niche" of the real time embedded OSes?
BlackBerry nowadays is... well let's say the mobile world is basically divided into 2 sides these days: Android and iOS :p
There are also more mainstream real time Linux distros e.g. Yocto Linux