*Draft* DIMSUM architecture paper available

[William S. Frantz]

> 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