Scribit Jonathan S. Shapiro dies 27/04/2006 hora 09:06: > No no. You *really* don't understand. The process that is forwarding > *cannot* change the PP. You can only change the PP on an FCRB that > *you* allocated.
That was clear for me. > > I understand that, really. The problem is, what happens when payload > > match, when invocation purpose was to test the validity of the FCRB? > You don't invoke the sender capability for this. I was partly confused by this in a previous mail: > there is no difference in behavior between invoking a Null cap and > invoking a cap with a non-matching payload That led me to think that your check was to invoke the capability. And it didn't make sense a check. > You invoke Discrim, passing the reply capability as an argument. > Discrim will respond with: > > clOther if capability is a reply capability and PP *does* match > clVoid if capability is invalid > > [Note bug: this should be called clInvalid, and I will > update the spec.] > > A capability is considered invalid exactly if: > > 1. The target object that it names has been destroyed (severed), or > 2. The capability is a sender capability to an FCRB, the PM bit of > the FCRB is set, and the PP does not match the PP of its target. Then the specification is incomplete, IMHO. Section 6.1 tells that invoking a capability with wrong PP where there is PM triggers an InvalidCap exception, but nothing tells that the cap in itself has become a void capability, and that discrim would see it that way. > Does my description above answer your question? Almost completely. Will coyotos.cap.getType() return the ID of a void capability, or only Discrim could see the invalidity? So the protocol becomes: Successful operation: ===================== - C invokes a cap to S, giving S a cap c1 to a FCRB->C - S sets up a watchdog that check that discrim.classify(c1) != clVoid - S invokes a cap to T, giving T a cap c2 to a FCRB->S - T sets up a watchdog that check that discrim.classify(c2) != clVoid ( T successfully treat the request, now goes completion ) - T invokes c2 - S reads the answer, and increment the PP of the FCRB->S - S invokes c1 - C reads the answer, and increment the PP of the FCRB->C Uncomplete operation: ===================== - C invokes a cap to S, giving S a cap c1 to a FCRB->C - S sets up a watchdog that check that discrim.classify(c1) != clVoid - S invokes a cap to T, giving T a cap c2 to a FCRB->S - T sets up a watchdog that check that discrim.classify(c2) != clVoid ( for any reason, C decides to stop, now goes cancellation ) - C increments the PP of the FCRB->C - S watchdog notifies S of cancellation - S increments the PP of the FCRB->S - T watchdog notifies T of cancellation Which shows that the only thing needed to add cancellation forwarding is a watchdog on the validity of the reply cap. Which is quite marvelous. Clearly, Nowhere man PS: is there a way to access to the source of the specification, to propose a patch? -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
