On Fri, Jul 4, 2014 at 10:11 PM, Matt Oliveri <[email protected]> wrote:
> On Fri, Jul 4, 2014 at 11:48 PM, Jonathan S. Shapiro <[email protected]> > wrote:>> It looks > >> like Coyotos itself doesn't need to care what constitutes an object > >> implemented by an application. It just needs to faithfully report the > >> (uninterpreted) protected payload and OID to the appropriate process. > > > > That is exactly correct. > > ...except that OID should've been endpoint ID? > Oh. Yes. Sorry. So basically, you ask one image to compare itself to the other, hoping > it would recognize itself. What if these were secure objects possibly > implemented in different processes, and you don't want to grant one to > the other? > Actually we don't need to get into details, the point is that it isn't > the kernel's problem. > It's only the kernel's problem to the extent that the kernel implements the necessary primitive operations. In this case: Discrim and identifyEntryWithBrand > > Right. And that's the point. You can build very rich systems without > having > > much to say about object identity, and without letting applications in > > question even ask the question about object identity. > > You reminded me that E and Joe-E disable object comparison by default. > Where does BitC stand on primitive object comparison? > Norm and I go back and forth on this. In the context of a stateful system, I'm not really opposed to EQ. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
