At Sat, 22 Apr 2006 19:00:54 +0200, Marcus Brinkmann wrote: > But it is you who is not thinking clearly: I have not said that the > client should rely on unreliable code for anything. I have said that > the client should rely on the kernel to send a notification when the > reply capability is dropped. I also claim that such a guarantee > allows me to state invariants of the system that allow me to reason > about the ability to recover from bugs or hostile behaviour in some > use cases.
Here is, in an informal manner, one of the invariants I mean: When a process is in a call, and waiting on a reply (send-once) capability, from a global system perspective one can identify a process "on which" the caller is waiting: Namely the process holding the reply capability. This is true of course because the reply capability can only be moved around (or invalidated by generating a message on it via invocation or implicitely by dropping it). This sounds like a useful property to have, because now one can, in principle, always find a task responsible for another task waiting on a call. I do realize that this is a narrow view, ie I am not claiming that this is generally useful. However, I do not know how to efficiently implement the above invariant without a kernel extension, which leaves only one possible alternative: That the system should be designed so that the above invariant is not required in argueing about functional aspects of the system behaviour. But what would replace it? Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
