Top Level Conclusions

The QNX information referred to below is a good architectural description as far as it goes, but it fails to reveal the authority procnto uses to provide the Unix like functions that it provides. How is it less powerful than the kernel. If it is as powerful, why are we to consider it outside the kernel? To achieve the power of a capability system it is necessary to supplant some of procnto lest we merely have a small Unix.

There are suggestions that the file system and other system functions runs as user processes, perhaps like Mach. I will assume for now that they have Mach’s drawbacks.

Notes as I studied the documentation

This page seems to be a good architectural view of QNX. Text below between square brackets is taken from that document and can presumably be searched for by the browser to find the context of my remarks.

[POSIX API]: We have provided a good deal of Unix functionality in some of our ports but this is not central to our strategy. Our dissatisfaction with Unix goes rather beyond the size of its kernel. The main advantages of our architecture are not available without application code that is savvy about capabilities. There are, even so, critical programs that can be brought blindly from the Unix world with a modicum of Unix compatibility. The 88K port ran an unmodified X11 server.

[scalable] While Keykos is not the smallest kernel I have heard of, It ran production in 1 MB of real storage. That may count as a constrained environment these days. It has been architected for symmetric multiprocessors but some kernel code is still lacking. The strategies for managing hardware resources are from the IBM main-frame tradition.

This is a clear but partial description of the QNX kernel. It describes kernel thread functions much like Unix. Their TLS (thread local storage) seems to be storage cells that are not mapped into the shared address space common to the threads. I wonder if it isn’t cheaper to have a thread specific page mapped into the thread’s address space.

I get a feeling that they don’t achieve the no stuck resources property of the Keykos kernel. Much of the description is in terms of the semantics of the library calls. My impression is that we could meet their library semantics with a different library more easily than they can.

Their section “Synchronous message passing” describes a message passing scheme like Keykos except It is like Keykos in that Messages cross “Channels and connections” which I shall interpret as capabilities. There is a c-list index and one c-list per process (one address space per process).

Their channel is like:

IP
a receive port
Keykos
A start key to recipient with distinguished data byte
Joule
distributer
I do not know how a program comes to have a connection on which to send to a channel.
Quote: “The procnto manager allows resource managers, through a standard API, to adopt a subset of the pathname space as a ‘domain of authority’ to administer.”. They speak as if procnto exercises infinite authority as does the kernel. In any case you seem to be subject to it. I think their authority dissemination is like that of Unix. Indeed there is a great deal of Unix function in their kernel. Their file system is a monolithic object outside the kernel (like Mach) but it sounds like it is one per machine — not user replaceable.

How procnto itself wields authority is left mysterious. The effect of ChannelCreate(...) is to create a port via which you receive messages from others. I cannot find out how others become connected to this particular port. Is the ability to connect to this new port (channel) disseminated as a capability?
The kernel plus procnto is clearly not a capability system. I can’t tell about the kernel proper.