Hi, On Mon, Nov 17, 2008 at 12:39:30AM +0000, Zheng Da wrote: > On Wed, Nov 12, 2008 at 1:18 PM, <[EMAIL PROTECTED]> wrote:
> I am quite curious: why did porting to the modern microkernels fail? Well, it's a long story, and I don't understand all the details myself. I'll try to give a very rough summary. The original L4 (Pistachio) turned out unsuitable, because it totally lacks any capability support in the kernel. Implementing it in user space proved not feasible. L4ng and L4.sec add some kind of capability support, by extending the mapping idea from memory to other kernel objects, including communication channels. One of the problems here was that the hierarchical mapping system is quite different from the copy semantics normally used in capability systems. (It was never finally concluded though whether the lack of copy semantics is a problem for the Hurd...) There were some other problems as well. I remember some talk about an identify operation on capabilities, and about endpoints. There was also something about kernel memory management. It is not clear whether it would have been possible to implement the Hurd on L4ng or L4.sec nevertheless; but it was quite clear by then that it would have required quite a lot of fiddling to implement our desired semantics -- leaving us in a similar situation as with Mach... Anyways, by that time Shapiro managed to convince Marcus that Coyotos would probably be a better foundation, because of the specific problems described above, as well as the general observation that the Coyotos group has years and years of experience with such capability designs, while it's totally new ground for the L4 folks. But Coyotos as it turned out has other fundamental problems regarding our goals: The constructor mechanismm helps putting users out of control, thus being in direct contradiction to the GNU philosophy. Also Coyotos avoids any self-management of scarce system resources by the applications -- while this was indeed one of the main ideas behind Hurd/L4. And the persistency approach doesn't really make sense for a general purpose system like the Hurd. > then come a question: what kind of microkernel does Hurd need? That's the core of the problem: we do not really know ourselfs... The point is that microkernel design is very tightly coupled with the design of the rest of the system, which is precisely why a kernel created in another context is never likely to be really what we need. Viengoos probably comes as close to an answer as we get -- after all, it is the conclusion (well, Neal's conclusion at least) from what we learned in the attempts with other kernels... > > In any case, IMHO we have much more pressing issues than Mach's > > shortcomings presently, and thus I don't consider work on new > > microkernels the highest priority right now... (Definitely > > interesting though.) > > but I think at least some bugs in Mach should be fixed. Yes of course! I didn't mean ignoring the microkernel alltogether. I meant that IMHO the Hurd on Mach should remain the main focus for now -- which obviously implies fixing the less fundamental problems in Mach. -antrik-