News for hackers. Stuff that matters.
Re:Dissecting QNX [pdf] by ahati on Wednesday September 19, 2018 @02:37AM (#18022212)
Anyone working on QNX based system here?
Re:Dissecting QNX [pdf] by exDM69 on Wednesday September 19, 2018 @08:10AM (#18023584)
Yes. Working for a HW vendor catering to automotive and embedded customers. QNX is one of the five or so OSes we work with.
Re:Dissecting QNX [pdf] by insulanian on Wednesday September 19, 2018 @01:44PM (#18026078)
What are the other ones?
Re:Dissecting QNX [pdf] by exDM69 on Thursday September 20, 2018 @05:15AM (#18030844)
Linux (several flavors), Windows, QNX, GH Integrity, FreeRTOS and a handful of in-house and clients' proprietary special-purpose OSes.
Re:Dissecting QNX [pdf] by wolfgke on Thursday September 20, 2018 @06:59AM (#18031281)
Interesting. I would have expected that also

- 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.

Re:Dissecting QNX [pdf] by Cyph0n on Wednesday September 19, 2018 @08:01AM (#18023542)
Cisco's high-end router operating system, IOS-XR, has two flavors: an older one built on top of a QNX kernel and the current one built on top of Linux. The QNX version is still supported but is not in active development.
Re:Dissecting QNX [pdf] by wolfgke on Wednesday September 19, 2018 @08:22AM (#18023637)
Do you know any details on the reason why Cisco switched from QNX to Linux?
Re:Dissecting QNX [pdf] by tyingq on Wednesday September 19, 2018 @08:55AM (#18023809)
The official line...

"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...

Re:Dissecting QNX [pdf] by Cyph0n on Wednesday September 19, 2018 @10:39AM (#18024480)
That seems to agree with what I've heard internally. Granted, I'm new, so I didn't go through the migration phase.

XR itself provides abstractions on top of QNX and Linux, so devs working on platform independent code are not really affected.

Re:Dissecting QNX [pdf] by tyingq on Wednesday September 19, 2018 @11:00AM (#18024619)
Maybe also because things like DPDK (or similar) made it possible for Linix to play at that scale?
Re:Dissecting QNX [pdf] by Cyph0n on Wednesday September 19, 2018 @03:14PM (#18026893)
The routers I am talking cannot do packet processing on the CPU. We are talking about 3.2 Tbps per linecard with 10 linecards per router.

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.

Re:Dissecting QNX [pdf] by jxramos on Wednesday September 19, 2018 @01:36PM (#18026004)
One of my former employers was developing in QNX, as of 2017 they were still using some 2005 compiler for 32-bit.
Re:Dissecting QNX [pdf] by exikyut on Thursday September 20, 2018 @01:35AM (#18030013)
What general space were they working in? Networking, for example?
Re:Dissecting QNX [pdf] by jxramos on Thursday September 20, 2018 @10:50AM (#18032814)
Medical devices
Re:Dissecting QNX [pdf] by lsiebert on Wednesday September 19, 2018 @05:05AM (#18022877)
I don't myself, but my brother, who designs and builds stages for U2 and other musicians, uses it for automation (lights etc.)
Re:Dissecting QNX [pdf] by ahati on Wednesday September 19, 2018 @01:57PM (#18026206)
Does he use the AMX systems. That is Harman, Harman used to own qnx before.
Re:Dissecting QNX [pdf] by mmorriso on Wednesday September 19, 2018 @04:48AM (#18022823)
Yes, I maintain a few legacy system that still operate partially on QNX 4.25

It did a few really cool things for its time, considering that TCP/IP networking was an optional add-on when we originally deployed.

Re:Dissecting QNX [pdf] by bregma on Wednesday September 19, 2018 @09:32AM (#18024021)
Yes. I work for QNX. I can answer any technical questions.
Re:Dissecting QNX [pdf] by vmsp on Wednesday September 19, 2018 @01:06PM (#18025721)
What's your goto intro/reference to QNX's internals?
Re:Dissecting QNX [pdf] by bregma on Wednesday September 19, 2018 @04:27PM (#18027445)
I have access to the code. There is no more reliable reference. The source code is remarkably well organized and clearly coded and has massive amounts of unit tests.

When the code is not enough, I go to http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.qnxsdp...

Re:Dissecting QNX [pdf] by ahati on Wednesday September 19, 2018 @01:58PM (#18026227)
How much is the difference of qnx7 and 6.4 at kernel source level? 6.4 source is available in github from time qnx was made open source.
Re:Dissecting QNX [pdf] by bregma on Wednesday September 19, 2018 @04:20PM (#18027383)
The biggest difference between 6.6 and 7.0 in the kernel is mostly that SMP is always enabled and 64-bit targets are first-class citizens. There are plenty of minor changes, but the kernel itself is very, very small.

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.

Re:Dissecting QNX [pdf] by exikyut on Thursday September 20, 2018 @12:07PM (#18033489)
Hi! I have a couple questions I've been wondering about for years. Appreciate any insight/answers you can provide.

--

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.

Re:Dissecting QNX [pdf] by Kenji on Wednesday September 19, 2018 @02:52PM (#18026706)
I can tell you some of that. We ported all our applications from QNX6.5 to QNX6.6 and then QNX7.0.

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.

Re:Dissecting QNX [pdf] by jayalpha on Wednesday September 19, 2018 @04:33AM (#18022754)
Re:Dissecting QNX [pdf] by TheSoftwareGuy on Wednesday September 19, 2018 @11:57AM (#18025126)
Yup, my companies product is actually mentioned on the first page of the link
Re:Dissecting QNX [pdf] by cornellwright on Wednesday September 19, 2018 @12:01PM (#18025164)
I've used it on medical devices.
Re:Dissecting QNX [pdf] by Kenji on Wednesday September 19, 2018 @07:25AM (#18023377)
Yes. I work with QNX6.6 daily. I also worked with QNX6.5 and QNX7.0. It's a real blast to work with the mikrokernel. It's a really cool system, and the kernel stability is excellent. Feels good that when a low level driver crashes, your system just goes on as if nothing happened (except, of course, the applications that need this driver). Speaking of drivers, the driver situation on QNX is a bit sad, simply because there are few drivers and the ones that exist aren't as high quality and well tested because QNX is niche. Still, if there was a QNX environment that is as progressive as Linux Ubuntu (concerning GUI, drivers, etc.) and OpenSource, I'd definitely use QNX as my main OS.
Re:Dissecting QNX [pdf] by ahati on Wednesday September 19, 2018 @02:00PM (#18026249)
Can not agree more. Once you know qnx, nothing matches up anymore. Linux feels like dinosaur.
Re:Dissecting QNX [pdf] by na85 on Wednesday September 19, 2018 @10:28AM (#18024399)
>QNX is niche

What is the most mainstream or perhaps "least niche" of the real time embedded OSes?

Re:Dissecting QNX [pdf] by anta40 on Wednesday September 19, 2018 @10:48AM (#18024534)
Hmm... BlackBerry 10, perhaps? https://help.blackberry.com/id/blackberry-security-overview/...

BlackBerry nowadays is... well let's say the mobile world is basically divided into 2 sides these days: Android and iOS :p

Re:Dissecting QNX [pdf] by jjoonathan on Wednesday September 19, 2018 @10:58AM (#18024602)
What? BlackBerry is realtime? Why?
Re:Dissecting QNX [pdf] by monocasa on Wednesday September 19, 2018 @11:35AM (#18024951)
So you have the option of running the baseband on the application processor to save costs if need be, among other reasons.
Re:Dissecting QNX [pdf] by ahati on Wednesday September 19, 2018 @02:07PM (#18026311)
You need a hypervisor for that. Qnx brought that later.
Re:Dissecting QNX [pdf] by dfox on Wednesday September 19, 2018 @02:45PM (#18026639)
You don't. Symbian EKA2 platforms (eg. S60 3rd edition and later) used to run baseband as userspace threads on same core as user applications. I would not be that surprised if that was main enabler for Nokia E51/52, ie. full-featured smartphone in executive-phone form factor (small and in the first place thin candy-bar).
Re:Dissecting QNX [pdf] by gnulinux on Wednesday September 19, 2018 @02:22PM (#18026428)
There is linux-rt, a fork of linux but I don't think it's competitive in the industry.
Re:Dissecting QNX [pdf] by roymurdock on Wednesday September 19, 2018 @12:56PM (#18025637)
VxWorks/FreeRTOS

There are also more mainstream real time Linux distros e.g. Yocto Linux

Re:Dissecting QNX [pdf] by nickpsecurity on Wednesday September 19, 2018 @11:54AM (#18025112)