Owning Resources & Capabilities Thereto

By resource I mean here physical parts of the machine and not the information or behavior that might be found there. Some include information under the term “resource”. Perhaps “capability to capacity” would be less confusing than “capability to resource” but “capacity” is a mass noun which is not appropriate here.

There are three kinds of resources that will concern us mainly:

Storage
with which to carry information from one time and place to another time at the same place,
Channels
with which to carry information from one time and place to another place at the same time,
Processors
with which to transform data.

Some examples before the Generalities

I had hoped to build a taxonomy of objectified resources but I find a zoo instead.

In Keykos there are two sorts of capability to space:

Keys designating nodes are enough like page keys that we will ignore them for these notes. These are both primitive. A range key is more primitive and powerful in that it conveys permanent access to some fixed portion of disk space. A range key will, on order, create a page key to some particular page frame on its part of the disk. We say that this ‘creates a page’ or that the caller ‘buys a page’. Another order on the range key destroys every page key to some specified disk page frame on its part of the disk. We say that this ‘destroys the page’ or that the caller ‘sells the page’.

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.

To Back Off a Bit

Having jumped in head first, we now back off for a little perspective. CPUs are processors that: We are concerned here with the second role.

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!

This paper sounds relevant! Racket’s mechanism built around Scheme