The basic idea was to borrow concepts and hopefully kernel code to implement capability segments that were like data segments as appropriate. Offsets in data segments are integers that identify successive bytes. Such offsets fit in user mode addressing registers and are directly processed by the hardware. Capability segment offsets would identify successive capabilities. As pages form the primordial data segment then so would nodes or perhaps ‘cappages’ form the primordial capability segment from which all capability segments are built. I would presume that all capability offsets reach the kernel for interpretation via message as in normal invocation of kernel objects. This is in contrast to what I suppose is the current EROS scheme of code issuing commands that the hardware views as invalid and the kernel deducing the address to locate the real bits of the capability.

There are a few variations on implementation of the capability segment:

Perhaps the hardware TLB could be used to cache tree traversal work just as it does for data segments. This counts on page table semantics that are not uniform across hardware architectures. It also assumes that the capability segments occupy space in the domain’s address segment.

I lean towards making the domain’s address segment (better called a data segment, perhaps) disjoint from its capability segment. Only explicit key invocations would access the capability segment. Tables analogous to the hardware TLB could be kept by the kernel to cache tree walks.

A currently reserved lss (blss) in a node key could terminate a capability tree walk as does discovery of a page key in a data segment tree walk.

This scheme supports sharing capabilities and arrays thereof just as the data segment architecture supports sharing of data.

I would probably not favor this scheme unless both concepts and kernel code can be borrowed. (I want to keep the manual small as well as the kernel!)