[coyotos-dev] Guarded page tables

[Charles Landau]

[Replying to Coyotos-dev which seems more appropriate.]

At 12:54 PM -0400 6/14/07, Jonathan S. Shapiro wrote:
>HA/BG make GPT arity variable.

"Arity" means the number of arguments to a function. I would call this fan-out.

>We are now evaluating the following decision tree:
>
>
>1. Keep/Discard HA bit?
>    => Discard
>      2. Replace BG bit with index?
>         => Yes
>           All GPTs now same arity, BG cap can live in arbitrary slot

Is the BG slot traversable? That's undesirable; one might not want it 
to be accessible.

>         => No
>           GPTs have dynamic arity. Complicates data/control
>           dependencies.

I don't see the complexity with variable fan-out.

>    => Keep
>       2. Replace BG/HA with indices, add walk validity bitmap?
>         => Yes
>           All GPTs now same arity, BG,HA cap can live in arbitrary slot

I see no real benefit in allowing BG and HA to be in arbitrary slots.

>         => No
>           GPTs have dynamic arity. Complicates data/control
>           dependencies.
>
>We currently favor outcomes where the answer to (2) is "Yes". We remain
>on the fence about the HA bit [i.e. about kernel support for space
>keepers].
>
>Removing HA eliminates the need for NC protection bit. It appears likely
>that if HA is re-adopted, many of our applications will turn on NC at
>their space roots in order to be able to self-manage their spaces.

At 
http://www.cis.upenn.edu/~KeyKOS/agorics/KeyKos/Gnosis/29.html#noclapl 
there are two arguments in support of no-call, both of which seem 
weak, and one argument against it, which seems strong. I don't know 
what we were thinking when we put it into KeyKOS.