On Mon, 2006-05-01 at 04:44 +0200, Marcus Brinkmann wrote: > The meaning of the challenge, as proposed, is actually a very simple > one: The claim is that a strictly hierarchical process tree based on > the simple parent-child relationships is expressive enough for the > Hurd.
I have a longer analysis coming, but let me send the first part, because I think there is a very basic problem in your definition of "non-trivial confinement". You wrote: > With these definitions: > > creator := the creator of the confined constructor object > instantiator := the user of the confined constructor object > > Then: > > Trivial confinement <=> (creator == instantiator) > non-trivial confinement <=> (creator != instantiator) > It appears to me that this definition is not enforceable unless IPC is removed from the system entirely. Here is my counter-example. Perhaps I have misunderstood you, or perhaps you need new definitions. 1. I create a new constructor, so I am the creator. I put stuff into the constructor. I instantiate programs. So far this is all just "trivial confinement" as you call it. 2. In general, if I hold the ability to invoke an arbitrary process P, and I also hold the ability to communicate with you, then I can send you a capability that allows you to invoke process P. 3. The constructor is merely a process, so I can hand you a capability to the constructor. 4. You can now invoke the constructor, which is non-trivial confinement. I do not see how to prevent this without disabling IPC altogether. What am I missing here? If you agree with statement (2), then your solution is not restricted to hierarchy. It is restricted to the "rule of transitive introduction", which is *exactly* the same rule that applied to the original constructor mechanism. I suspect that I am correct, and that your problem with the constructor is not related to the instantiator vs. creator distinction. I will send a longer note trying to break the constructor down feature by feature so that we can learn which feature or combination of features creates the problem. But I definitely don't think that the instantiator/creator distinction is relevant. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
