Hi Tim,
I gather from a conversation I had yesterday that the dropping of Qnet could be some time (years?) away so this discussion is really academic at this stage. But I’d like nonetheless to put forward my view on the subject.
While parallel processing may have been an original justification nearly 40 years ago for developing the distributed processing feature (known thesedays as Qnet) I don’t think it’s been a viable justification since the days of QNX 2/3 and ARCNET some 25 years ago. So on that score I agree entirely with you.
For me Qnet allows me to transparently implement the powerful features of IPC (Inter Process Communications) either by use of the Resource Manager model (that I use extensively) or simple the message passing paradigm (SRR - that I also use extensively) seamlessly across a network. Why do I want to do this?
Well, I sometimes need to split processes/threads out of one single CPU environment (be it single or multi-core) to CPU’s that are for whatever reason physically detached. In one case I have a CPU that acts as a master system controller (MC) that also incorporates an instance of a different software suite (an “application” if you like) that the MC manages. Often I require multiple CPU systems, connected by a network (be it wired ethernet or wireless) that also run these “applications” that the MC provides overall management and control.
Qnet allows me to simply move the applications to different CPU’s without any need to change anything other than the path names. I don’t have to implement TCP/UDP mechanisms - from the point of view of the MC “/dev/application” simply becomes “/net/cpuname/dev/application” and that’s it!
Using Qnet I can continue to employ pulses for event notifications without changing anything in the code. In fact, everything to do with QNX IPC that can be done locally can be done remotely without requiring any fundamental changes to the system architecture. This to me (at least) is a Very Powerful Feature that sets QNX apart from anything else.
For 25 or so years I have been maintaining a QNX serial driver for a well known PCI multi-port serial I/O product (the RocketPort). This product also had (of course) Windows and Linux drivers. But it was becoming harder and harder to run serial lines/cables around buildings/factories. Often the system controllers (hosts if you like) would be in one location but the machinery requiring the serial interfaces would be somewhere else. While there was resistance to laying serial cables generally there would be networking cables (Cat5/Cat6) going everywhere. As a result a new serial product was developed, often referred to as a “serial device server”. It’s basically an ethernet to serial port converter. We looked at developing a QNX host to connect to these serial device servers but it quickly became apparent that the effort was simply not required. As one guy in the broadcast industry said to me (20+ years ago and I quote) “if I want access to remote serial ports I’ll simply install a QNX box with a RocketPort and manage it remotely across the network”. He was simply referring to the capabilities of Qnet - his was a QNX shop. We simply didn’t need to develop a special driver as QNX provided us with a solution simply “out of the box”. So I never did.
I can think of many such cases. The ability to seamlessly communicate between multiple remote CPU environments (such as wind farms, even cars/motorbikes, etc) without having to resort to 3rd party solutions or a diferent protocol suite should not be under-estimated!
As for the little “file server”, using Qnet I didn’t require a Samba server to be running. I’m not even sure if there is a fs-cifs Samba client available in 7.0 (I’ll go looking later this morning). While I have a Samba server running on 6.5.0 I don’t remember seeing one that runs on 7.0. I don’t know about 7.1 as I don’t yet have 7.1. Maybe there is - if not what’s involved in building it? To me none of this mattered - with Qnet I didn’t need to even consider that approach. I was able to quickly solve my problem using the tools provided to me by the operating system in a couple of hours and with no need to implement 3rd party solutions to a problem QNX solved decades ago.
I fervently hope that Qnet is not removed in the future. But even if it is dropped in the future, there are so many other powerful features of QNX that I can’t at this time see myself moving away from it. But the flagged possibility does force me to alter my approach to the research project I’m involved with at one of the local universities, where I’m trying to teach students (at least when they come back post COVID!) the dark arts of QNX as opposed to Linux! 
Cheers,
Geoff.
