There are three kinds of resources that will concern us mainly:
In Keykos there are two sorts of capability to space:
A page key yields temporary ability to store and retrieve data. In normal operation all range keys are held by space banks of widely trusted behavior. There is no particular reason, however, that range keys need be denied to untrusted programs, providing that those keys provide no access to disk space in use by others. There are no provisions for rescinding range keys other than reformatting the controlled portion of the disk so that those keys no longer access it. (On the 370 a device key is required to format a disk.)
Page keys and range keys do not directly grant access to RAM. RAM is used merely as a disk cache. There are applications that require combinations of RAM (as distinct from disk) and CPU on definite schedules. The current Keykos kernel has no architected way of providing this. It is tempting to provide for RAM something analogous to the keys that we provide for disk. The volatility of RAM gravely weakens the direct application of these ideas. Another possibility is to implement kernel rights to fungible RAM. Some mechanism would limit the total of such capabilities. Such a capability would be honored directly by the kernel. The specified but unimplemented Keykos charge sets may provide some ideas here.
Schemes for fluent IO can be adapted also to processors and make good sense combined. Reservations for bursts of processing can also be valuable in batch processing for month end tasks. In this case it is likely that the same pattern on grossly different time scales will require somewhat different software.
Keykos meters are used to measure and allocate CPU resources.
Some application requirements are for a steady stream of capacity throughout an extended time period. A sound stream to support real time capture, presentation or transmission requires prompt but brief access to transmission capacity and perhaps processing. Less than all of the underlying facility is required. Low latency demands on the application may require very frequent access to the CPU and transmission facilities. Only the kernel may be able to respond quickly enough to schedule the application code. Indeed in the extreme case the application code may need to run during the interrupt. This is how the Mac supports the mouse cursor on the screen. Allocating capacity in many small chunks be possible only for the kernel, or indeed only by the hardware, as in Firewire.
Each of these resources should be allocated via capabilities and each such capability is grounded on some sort of primitive capability honored by the kernel. In Keykos we would say that such capabilities designate primitive kernel objects. We will consider here both primitive capabilities and higher level capabilities implemented ultimately upon the primitive ones. It will emerge, I think, that the stack of functionality is ordered differently for different kinds of resource. Yet many design patterns will be in common.
The most specific authority will designate a particular resource element and a specific time duration.
The end of the duration may be bound within the object or there may be an external capability with which to abort the tenure. The distinction may be a matter of style of specification!