I think that was a mistake that in Keykos the SBT is the arbitrator of official banks, and source of new banks. Asking another trusted bank is a better design. Keykos may change. SBT was an early invention. Note, however, that SBT is available to the factory yield and a suitably weakened bank may be necessary as a component, against which to test the quality of the bank passed via the requestor’s key.
Charlie notes three reasons for verifying a bank. There are others, such as durability. Indeed the manual speculates on a whole lattice of such attributes. Which of these can be done with bank keepers?
As Charlie says: “The official Domain Creator is fundamentally interrelated with the official space bank.”. Indeed each must trust the other to ensure its own correct operation. They are in cahoots. In the big bang this requires special kludgery concerning which comes first.
Let me mention an application very much like what Charlie suggested in the way of a bank that produces audited nodes. We were recently debugging a new kind of segment keeper and used a somewhat kludgy mechanism to log all key calls. Seeing as how the machine was not being shared this was serviceable. Employing a bank that delivered audited nodes would have served even better in some ways, especially in a shared environment. If we had passed such an extended bank via the factory requestor key, however, it would have been rejected after consultation with the SBT. Even using in a factory with a fake SBT, which we could legitimately arrange as the holder of the factory builder’s key, the internal domain creator would have barfed upon seeing the fake bank. A real DC needs real nodes!
One fix is to provide a factory equipped with fake: SBT, DC. (If the SBT is eliminated the two fakes are SB & DC.) This presumably illustrates the advantage that Charlie’s scheme yields in that only one substitution is necessary.
The legacy domain problem seems to want a space bank that is agnostic to machine instruction set architecture. This is a reason not the unify DC and SB. The IA64 kernel is likely to have native (in kernel) IA32 and IA64 domains. I see no inherent need to make them unsymmetrical.
Charlie raises problems with the current architecture but there seem to me to be disadvantages to the unification, such as what instruction set does the domain from the unified provider obey?