Comments on Genode

Keykos is in the category of operating systems that present the illusion of ‘allocate memory from an unlimited pool’. Well not actually unlimited but the limit is much larger than real memory. Keykos does, however, account for ‘resources used by the kernel on behalf of application’. This is because those resources are not in the kernel. Keykos is like Genode in this respect. The Keykos kernel includes extra logic to achieve this illusion. This makes some TCBs larger and others smaller. It decreases the cost of applications unless Genode has managed to abstract such logic in Genode objects. The Keykos virtualization of memory and time does not by itself lead to nondeterminism. The Keykos space bank supports ‘trading of resources’ across arbitrary boundaries.

Device drivers for the IBM 370 were simplified by IBM’s channel architecture that eliminated the real-time aspects of IO from even the kernel for all the devices that we needed. All drivers aware of the architecture of some particular device were outside the kernel except that our virtual memory support knew about real disks. Devices attached to more modern systems may go thru similar interfaces such as SCSI or USB either of which need kernel specific support. Displays are an undocumented mess.

The first three paragraphs of the index for architecture describes what they do and why they do it. It covers Keykos as well.

They go on to describe a tree of objects with a root at the bottom image wise. A ‘parent’ seems to create and control a child one node up in the tree. I don’t know if this is a convention or something enforced by kernel functionality. It is reminiscent of the Keykos big-bang but in Keykos some of the root domains cease any role early-on. I am not sure whether the tree is in fact a limitation. “The root capability is intended to be used and kept by the parent only.” The word “intended” leads me to believe that they are describing a conventional pattern rather than a kernel enforced rule.

I think that a node in this tree can serve in two sub-patterns:

It can server as a ‘creator’ in the Keykos sense and an invocation creates another node which is a sibling of its earlier yields.
It can be an instance.

They seem to consider CPU resources in the quota. More later.

This page describes interaction patterns that suggest to me that the tree structure is imposed by the kernel. There is no hint of a call mechanism between nodes and issues of kernel stack exhaustion. Still this explanation feels like a view from atop a run-time library that imposes its own style. At this point in the Keykos design documentation, one could do co-routines.

I presume that the “core node” is a user mode program that doles out RAM. No Keykos domain code deals directly with RAM. I do not complain.

From this I get the impression that capabilities (their word) are only to services, like Keykos ‘start keys’. Perhaps the limitation to tree structure is due to lack of RAM capabilities or resource capabilities.

They describe their goals here rather well. I think that Keykos achieves all those goals. I suspect that both achieve many lesser goals as well.

Guessed Terminology Map

Keykos	Genode
facet	interface
domain	node
slot	slot
general keys node

regarding this document: “However, the optimization for high utilization comes at the price of indeterminism and effectively makes modern commodity OSes defenseless against denial-of-service attacks driven by applications.” The Keykos kernel guards against DoS and provides ‘unlimited’ virtual memory as well.