The privileged code of Keykos, called the kernel, has no concept of class except for a simple order on the domain tool, a kernel object. Domains are the primitive objects that obey user code and thus implement objects with behavior defined by that code. A domain is “branded” by some particular key (capability) that occupies a special slot in the root node of the domain. Domains that behave alike generally have the same brand and conversely. Conventionally they obey the same code. In practice they are like different instances of the same class.

When a program X needs a new instance of some particular brand (class), it invokes the creator C which specializes in that brand. C is just an ordinary user defined object that is in a unique position to create such instances by virtue of some particular keys that it holds. One such key is for the read only segment that holds the machine code that is shared among and obeyed by the domains of that brand. When C was new, it invoked the domain creator creator (sic), of which there is just one, to get a new domain creator, DC. This new DC comes with its own unique brander B which is a key that it uses to brand domains that it creates. When DC is invoked it buys a few new nodes, fits them together, inserts its brander in a special slot in the root node of the nascent domain. Thus is the nascent domain branded and DC’s brander B becomes that domain’s brand.

Now the DC calls the closely held capability domain tool, passing the node key to the root node of the domain. The domain tool is implemented in the kernel and it returns the domain service key DK, depending on the Keykos literature that you read. The DC has already finished with and discarded the node keys with which it fit the nodes of the domain together. It now discards the node key to the domain’s root node. It returns DK to its caller C. Then C returns DK to its caller X as a new instance of the branded object. C discards its copy of DK.

C fills in a few special slots into the new domain, D, such as its address segment which includes the code, a meter, a program counter that locates the code that will interpret the first message to D. C invokes DK to install the key for the code, and a few other keys that the domain may need for its charter. C then invokes DK to get a start key S for the domain. If D has facets, C invokes DK for a start key for each facet.

This is a description of the same process emphasizing different details. At this point absolutely no kernel brand logic has been used. To the kernel the brander is so far just another key that has been copied around.

The brand of this object might never be observed again but if S is passed around, some holder Y of S may wish to verify that S is indeed of the sort (class) that he requires. Y sends S to C with the query “Did you make this?”. (A common case of this is where Y is of that sort too and wishes to recognize a sibling. In this case X might respond with a special start key with which the siblings can converse with assurance of siblinghood.) X has made many instances and has not kept the DK’s or S’s for any of them. X still holds the key to DC, however, and sends S to DC with the same query. DC, likewise, once held the DK that it got from the domain tool, but DC discarded DK too. DC invokes the domain tool once more with another order: “Does the brand of the domain designated by this here key S match this here key B?”. DC has held onto its brander, B. The domain tool in the kernel can compare the brander with the brand. If they match the domain tool returns both the node key to the root node of the domain and the original DK which DC once held but had discarded. If DC had been asked to delete the domain it would now be able to sell the nodes back. If DC had been asked to open the node it would pass DK back to its caller. In the order at hand, DC replies “yes” to the query. C passes back the positive response to Y. If you trust the object to report its type then an alleged type call may suffice.

Notice that the brand is never invoked, but only compared for equality with other keys. This scheme is within the more general synergy pattern.

I have described the earliest design style for object creation. Primitive objects are still created that way. Typically the custom creation code for these primitive types lives in the same segment as the code that instructs the instances. Generally, however instead of having a distinct ad-hoc creator object for each class, we have a factory instance for most brands, one instance per brand. The factory is parameterized upon creation for the particular needs of instances of the new type.

To recapitulate we have:

The function of DC could be folded into C or a factory without a security impact, but that would further scatter knowledge of the underlying hardware and kernel architecture.

This DC has the only ability to open a domain that it branded, which means to retrieve the domain service key from a start key. This ability stems from holding both the type’s brand and the domain tool. One DC is thus unable to open domains from another DC.

See about debugging in Keykos which need not violate security. The domain creator is used here also to open domains that must be examined or repaired.

This paper uses “brand” for a similar problem. I have not taken the time to compare the two notions.