The idea is to try to model a keeper design for a space bank after the keeper design for the meter. The meter is a kernel object but the bank is not. This should not be a problem. We want to introduce a bank keeper to complete the ancient idea of the non-prompt bank and also remove some hairy policy from the current bank and support new policy without burdening just about everyone’s TCB. We must beware the hot page scam and the confinement bug. This design is very much in flux, as will be apparent. I should try for a Guttag definition.

I speak here as if a bank creates a page.

The scheme described below is a bit like the ideas of the unprompt bank except that in this scheme one bank plays both roles.

World State

There is a relation between [pages|nodes] and banks.
A [page|node] is Of a bank.
(I want to postpone how this is implemented.)


Every [page|node] is Of just one bank.
Relax. We will not need to find the bank of a given page. We will need only to determine if a given page is Of a given bank.

State of bank

Constant{?} Key to superior bank.
Start key to keeper
nodeLimit, pageLimit, both non-negative integers.
Whether a [page|node] is Of a bank is really state of the bank. I don’t know yet whether to make it abstractly so.

Orders on a bank

[buy| sell] [1| 2| 3] [nodes| pages] [promptly| ].
for sell: Each [node|page] must be Of the bank.
for buy: Each [node|page] will be Of the bank.

To buy a [page|node] from a bank the bank rejects the order if the Limit is zero or if the superior bank rejects the same order. If the Limit is 0 then the bank’s keeper is invoked. The returned [page|node] key will be the only key to a [page|node]. Quibble: well actually the bank and superior banks retain a key to the page just as commercial banks can get into your safety deposit box. But if you believe that the returned key is to a page you may as well equally believe that you have the only key to the (new) page.

If you sell a page to a bank the page must be Of the bank. The Limit will be incremented and the page key (and its copies) will be rescinded. There are several bugs in the above but I think the intent is clear. The biggest question is which resume key is passed to the bank keeper, and which other capabilities.

Perhaps the original order is passed to the keeper including the resume key.
This won’t work for the bank keeper is not to be trusted with the keys to the new pages.
Perhaps the bank could package the request into a node and deliver a segment key for that node to the keeper.
But there is no end to the number of such messages and thus no upper bound on such storage required.
Perhaps the realm’s meter could be turned off.
I wonder about the performance implications.
Upon additional space being granted, the order can be redelivered to the original bank whereupon the original buyer will get what he asked for.

To buy a page promptly, the reserve must be positive, else the order is rejected.

Read limits
Return nodeLimit and pageLimit of this bank.
Sense superior limits
Return minimum nodeLimits and pageLimits of this and superior banks.
Set limit
Set nodeLimit or pageLimit of this bank. (Perhaps atomic form of read and set)
Augment reserve
This is like buying unpromptly except page keys are not returned. Instead the Reserve is increased by x and the Limit is decreased by X.
Each [page|node] is no longer.
Any [page|node] Of the bank is now Of the bank’s superior.
Transfer subservience
Transfer to Bank
bank is an official space bank and after the order the superior will be Bank.
This may be infeasible to implement.

Maps from Banks to Meters

The reserve of the proposed bank is a bit like the meter cache. Only domains have meter caches and not meter nodes proper. Also the meter cache is abstracted from user land. The reserve seems to reify the cache in the case of banks at least so that the factory will have access to a prompt bank, in order that it not be hung on an unprompt bank.

The proposed bank limits are almost exactly like meter counters. Service stops when the counter reaches zero. These bank limits however can move either direction.

Pinning down a reserve for a bank is a bit like pinning down a RAM frame—something that Keykos kernel does not do, but something that may be needed. The reason in both cases is for functions that are broken if they are not quick. The concept of quick is a bit different, however.

For just now I am working on the “Frame Perspective”.