On Fri, Jul 4, 2014 at 1:36 PM, Matt Oliveri <[email protected]> wrote:
> > I think we should take the question of the object ID notion up > separately. > > Well it sure looks like we should take it up. But I think it's > important for object id to be harmonious (for lack of a specific term) > with the way capabilities control permissions. Perhaps. In KeyKOS/EROS, the "discrim" capability (which implements EQ) was closely held. In Coyotos we were more liberal, and we haven't gotten into trouble yet. But in general we leave it up to the object developer to decide whether they want one capability on their "thing" to acknowledge whether it designates the same "thing" as a second capability. Doc for discrim: http://coyotos.org/docs/ukernel/spec.html#coyotos.Discrim There is a "capbits" capability that is VERY closely held. There's actually only one object that wields it in production: http://coyotos.org/docs/ukernel/spec.html#coyotos.CapBits The operation that inspires "guarded open" is the identifyEntryWithBrand operation on Coyotos processes: http://coyotos.org/docs/ukernel/spec.html#coyotos.Process shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
