[E-Lang] E FAQ

[Jonathan S. Shapiro]

> P.S. I double-checked on Hydra, and my memory was faulty.  It seems that
> Hydra was a hybrid.  Methods contain both ambient authority (hard-coded
> into the static source) as well as authority derived from parameters
> passed in by the caller.

This is not consistent with my recollection of Hydra. Hydra's protected
procedures could hold a capability segment independent of the one passed,
but I have no recollection of any ability to hard code within the code, nor
of any instruction supported by the VM that would have permitted this.

> Also, I think (but am not sure) that Hydra had
> a rather coarse granularity: not all objects were protected objects,
> and not all pointers were capabilities (i.e., references to protected
> objects).  I presume this was because it relied on the VM's page
> protection mechanisms, and thus performance and granularity are issues.

Hydra made a distinction between protected procedures (which would have been
better named protected modules) and normal procedures. A traversal into a
protected procedure involved a capability invocation. This constituted a
change of protection domain. Within a protected procedure, regular pointers
were used, but these were scoped by the active protection domain.

The VM's page protection mechanisms can be thought of as capabilities. What
is a page table entry if not a capability? In this regard Hydra was learning
from a mistake made by CAL/TSS, which tried to do memory management entirely
in software and got it wrong.

Wulf's book is strongly recommended to anyone interested in Hydra.


Jonathan