Re: IDL issue - struct return vs. cap return

[Jonathan S. Shapiro]

On Wed, 2007-07-11 at 15:46 +0200, Neal H. Walfield wrote:
> I suspect that this is not the case.  At least, I don't think they
> will be more widely referenced than memory or file descriptors.  Thus,
> for consistency, I think that whatever approach is taken for managing
> these resources (whether that be GC or explicit allocation and
> deallocation), should also be used for managing capabilities.

Hmm. That seems like something worth thinking about. There are a couple
of differences in the two models. One approach might be to try to
eliminate those differences.

1. Capabilities aren't file descriptors. A file descriptor denotes a
session between a client and a file server. The sesssion has an explicit
close() operation [either automatic or implicit]. The close() operation
provides a natural place to deallocate.

Capabilities do not have a corresponding close() operation, because they
do not denote a session. This raises the question "should capabilities
be sessionful?" That is a much larger topic, but I think that discussion
is worth having.

2. File-like operations tend to have the sequence:

    open()/create()
    use ... use
    close()

While descriptor permissions can be altered, they are altered "in
place"; no new descriptor is created. This design works because file
descriptors denote a session.

In capability systems, the pattern is that an operation of the form

        cap.reduce(byRestrictions)

that returns a NEW capability, leaving the old capability intact. The
receiver can elect to overwrite the old capability, but is not obligated
to do so.

This is a subtle difference in the model, and I'm not sure that the
close() idiom translates across this difference. I would welcome
opinions.

For capabilities that name files, we could implement either style of
behavior; it is purely a matter of protocol. For capabilities that name
primitive things like pages, there really isn't a session construct that
can be used to support this. Introducing sessions at that layer appears
to require kernel memory allocation, so I don't think that it is an
option there.

This introduces a problem, because whatever answer we come up with
should be uniform.


I will note in passing that we are both basically moving in the
direction of turning a cap_t into a capref_t, and we are now trying to
work out implementation details. This seems good (to me).


My statements above are mostly comments. They don't lead me to any
strong opinion about the right outcome.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC