Re: IDL issue - struct return vs. cap return

[Marcus Brinkmann]

At Wed, 11 Jul 2007 10:49:34 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> 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.

In the Hurd, a file descriptor is just a capability reference plus
fcntl flags and optionally a capability reference to the controlling TTY.

> 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).

In the Hurd, we always mean capref_t's when we talk about
capabilities.  In Mach jargon, this is a port name (more specifically:
a port name denoting a send or send-once right).  The actual
capability corresponds to the port, which is a kernel object named by
the reference (the message queue).

Because ports are never accessed directly, the term is used synonymous
to port name in most contexts.  The same naturally happens with the
term capability.

Thanks,
Marcus