The Map
Ah the map.
It seems as every cap system speaks a different dialect.
Even Keykos dialect has shifted over time.
“Zircon Kernel Concepts” is a place to start as it is recent and presumably establishes terminology.
“The kernel manages a number of different types of Objects. Those which are accessible directly via system calls are C++ classes which implement the Dispatcher interface. These are implemented in kernel/object. Many are self-contained higher-level Objects. Some wrap lower-level lk primitives.”
I am guessing that the “Dispatcher interface” is what some common C++ compiler compiles inter class references to.
In other words such calls do not cross trust boundaries.
Keykos does not speak of this but supports it.
Instead Keykos is careful not to screw up any language runtime support.
Somewhere I read their favorite language was Dart.
Perhaps Dart conforms to the Dispatcher interface.
My limited knowledge of C++ suggests the V-table.
Exploring some of the links makes me think that these are the concepts necessary to learn the internal kernel logic, rather than the concepts necessary to understand what the kernel delivers.
Keykos sometimes says it has just one system call; to invoke a key.
Zircon discriminates among their system calls according to what object is being invoked.
This is a distinction with little difference.
Job in which the calling Process is contained
This hints at a concept that has not been introduced which is some sort of relationship among processes.
It also hints about some “Job” and “Process”.
I am beginning to think that some earlier document is a prerequisite to this.
I see many differences between Zircon and either seL4 or Keykos.
Nothing fatal yet.
They try to make it sound like Linux; which may be strategic.
| Conventional | Keykos | Zircon
|
| Capability | Key | Handle
|
| System call | System call | System call
|
Notes: The Zircon handle is more like an index into a kernel held C-list.
The handle is merely a 32 bit number.
None of their text so far includes a capability; it may be a cap platform whose documentation has no noun for capability.