The idea is to try to model a space bank after the meter. 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 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 int 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.)

Physics

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]
[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.

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.
Recall
Each [page|node] is no longer.
Dissolve
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 the 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.

The frame perspective

Banks form a tree as in the original scheme. This defines the transitive superior and inferior relations between banks. There is for each bank a service key rather analogous to the meter service key.

Every frame is in just one of three states:

A reserved frame is reserved at just one bank.
An allocated frame is allocated at just one bank.
A frame is under a bank B iff it is allocated at B or at some bank that is inferior to B.
Every bank has a non-negative integer, its limit.

To buy a page non promptly from bank B, if the limits of B and of the superior banks are all positive then an available frame is allocated at B and all of those limits are decremented. A page is thereby created and returned the the buyer. If one of the limits is 0 then the bank keeper of the lowest bank with 0 limit is invoked with arguments: ....

To sell a page non promptly to bank B, the frame of that page must be allocated at B. The limits of B and all of its superior banks are incremented.