General Ideas

Just as there are kludges such as the CMSFILE and PAGES macros in the big bang logic which are used to import primordial code from the CMS world, so do we need other kludges to import primordial code arising from Gnosis technology. The L-segment factory {(p2,l-seg)} is just such a technology. We have begun to implement a deflator program that runs in Keykos to take an LSF key and produce data that can be made available at another time or another place for reinflation. The result would be an LSF surrogate that would serve as the original. This scheme counts on the presummed immutability of the LSF.

The inflator is sufficiently complex that we want it to run in a domain rather than in the kernel during big bang. We also want it to run with a comm link so as to transmit l-segs, after a fasion. A primordial inflator needs data that is somehow to be produced by the GNOSIS ASSEMBLE and INITIS ASSEMBLE technology which brings raw data from CMS land to Keykos. The seems to mean pages. If we make the pages suitable for the eventual use in the final inflated product we will not be wasting primordial pages. The deflator knows what ultimately belongs in pages and can divide its output into page oriented and other data.

The inflator thus needs access to an array of read-only page keys. This could be provided by something such as a super-node key without write rights. Random access to this array is required because the deflator will discover shared pages. Alternatively a primordial range key could be generated in GNOSIS ASSEMBLE to provide the required access to page keys. This is unsuitable to the comm application.

There is a huge problem with the above! There is no good way to produce a VCSK segment made of the primordial pages. But there may be an only slightly bad way. Bill points out that the security properties of VCSKs are not hereditary. The discretion of a VCSK factory does not stem from the discretion of an ancestor factory. One scheme is for a VCSK to adopt a ready made sensory tree. Another is to accept a page at a time.

An unusual attribute of the VCSK design is that two orthogonal security policies are supported. The VCSK's internal logic is abstracted and yet VCSK factorys are discreet.

When the deflator encounters a new page value it registers that value and associates it with a new small integer (the "encounter counter").

The deflator puts these new page values into an array of page values that is eventually transferred to CMS and thence to the big bang via a varient of the CMSFILE macro. The kernel module INITIS processes the PLIST entries produced by CMSFILE form some sort of KEYKOS structure accessible as an array to the inflator that runs in a domain. The GENSEG macro may be the right thing for this.