Matthieu has raised an interesting point. It may be that even if the L4 mapping database in general has flaws (an assertion that Espen and I are still sorting out), the Hurd's planned *use* of this system does not.
I want to suggest that this is a poor assumption to make. Here is the problem: We may be able to say with confidence: "No operation performed by the Hurd runtime will lead to any later operation that would require more than O(n) steps." Actually, I don't think we can say that, but I'm happy to let Matthieu and Neal try to convince me. The problem is that this is insufficient. What we actually *need* to say is: "No operation performed by *anyone* will lead to an operation that executes in more than O(n) steps." Here is the problem: our applications are not restricted to the Hurd API. They are also able to use the microkernel API directly. In consequence, careful design of the Hurd is an insufficient consideration for success. The microkernel must not allow applications to violate the requirements of the Hurd API. The alternative is to say that the Hurd will interpose itself and *interpret* all application syscalls. We are now arriving at a design that relies on many IPCs per system call. IPCs are not currently the bottleneck in microkernel performance, but they are still very close to the bottleneck. Double the number of IPCs per system call and you will definitely see a significant slowdown relative to monolithic systems. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
