[cap-talk] kernel object knowledge

[Mark Miller]

On 6/5/07, Peter Amstutz <tetron at interreality.org> wrote:
> From an efficiency point of view (as well as the extra work of
> reflection) I'm a bit uncomfortable with the E approach, whereby you
> create a restricted capability by defining a new class and a new object
> that isn't obviously connected to the underlying object without doing
> some degree of introspection.  I like the idea of being able to point to
> a simple bitfield that tells you which methods are permitted for a given
> capability.

There are two techniques in E for creating restricted access to common
state. The front-ending filtering forwarder, which you explain above,
or the forseen facet technique, as illustrated at
<http://www.erights.org/elib/capability/ode/ode-objects.html#facets>.
I added Norm's adjective "forseen" to describe this form of facet, to
emphasize that it's only applicable when the designer of the
abstraction anticipates the need for this packaging of restrictions.
When the need for a package of restrictions are unforseen, then the
filtering forwarder is your only choice.

<http://www.erights.org/enative/fatpointers.html> explains a technique
for implementing forseen facets that, I think, has the performance
properties you're looking for. We haven't tried it. If you do, we'd
love to hear how it turns out.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM