> In KeyKOS, segments, meters, and pages can be synthetically emulated
> only in a restricted sense. It is possible (even easy) for a process
> to expose the synthesis by plugging the synthetic versions into
> contexts where the kernel is not prepared to invoke a domain.
In KeyKOS, a synthetic page is a (red) segment defining one page. A synthetic segment is a segment which contains the origonal segment as it's data space with the no-call attribute (so faults go to the synthetic keeper). A synthetic meter is a meter which depends on the origonal meter, but is a fairly silly concept since calls to meter keys don't invoke the meter keeper, but are instead handled by the kernel.
N.B. These forms of synthesis allow one to intercept direct calls, and some of the traps. They do not allow one to intercept the passthru effects, such as mapping a page and then issuing load/store instructions to its address.
> 2.3 What is the contract with a real time process that doesn't want
> to use the CPU? Can it accuse DIMSUM of failing to meet its part
> of the contract?
>
> I do not understand. A real time process that does not use the CPU
> executes no instructions no matter how many cycles you give it.
This probably isn't relevant anyway. In the computer services business we were concerned with helping solve the delma where the real time user says, "You didn't give me the cpu"; and the service providor says, "You didn't want it".
> Perhaps I have misunderstood. In talking to Norm about various ideas,
> the meter hierarchy came up again and again as a way for supporting
> user-level policies about computon allocation. This seems to me to be
> essentially orthogonal to the notion of a group of collaborating
> processes.
Turning off a meter was the only to transparently stop one or more domains. As far as I know, outside of measuring CPU usage, stopping processes was the only actual use of meters. There never was any code which used them for scheduling in the model of schedulers in e.g. Unix.
> 7.2 Void Key - What happens when you halt? How do you test for a
> void key? The KeyKOS DK0 approach didn't always trap you. If you
> accepted the return code, then you could test for void as part of
> your normal outcome testing.
>
> DK0 was a sound idea, but I think it would have been better to have an
> invalid bit in the key in support of post-facto diagnostics, and not
> to have overloaded the notion of an invalid key with the notion of a
> data key. Thus void key. It needs to be specified, and I'm prepared
> to back off if it turns out to be a bad idea.
Many people agree with you. As far as I know, the only reason it was not added to KeyKOS was it didn't seem useful enough. Presumably invoking the void key would give a different return code from invoking a data key.
A more important issue is whether users can see the bits of a key. It may seem that it is a useful debugging tool, but it prevents a lot of stratigies that use front ends. KeyKOS had a "keybits" key, but it was only used by a restricted object, the "key indexed directory". In KeyKOS misuse of the keybits key would allow you to cause the reuse counts on objects to wrap quickly, invalidating one of the kernel design parameters. This could be avoided if you allowed the keybits key to return the same bits for two different keys. When you found the bits compared equal, then you would have to compare the keys to verify equality. (If they weren't equal, one or both of them would have become the void key.)
Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz@netcom.com Los Gatos, CA 95032, USA