Hi, On Sun, Nov 02, 2008 at 03:05:07PM +0000, Matthew Ayres wrote:
> No doubt this shows my naivety, but why has GNU never built its own > replacement for Mach? Well, I'm not sure what you are asking exactly here. This question can be answered in several ways... First of all, you may not be aware that Mach was originally chosen not because it seemed the best kernel for the intended design; but rather, first there was the decision to build something on top of Mach, and the Hurd design was a result of an attempt to make the best use of it. (The decision to build on top of Mach was made in the hope that it would be easier than creating a new kernel from scratch -- a tremendous misjudgment as we know today. Little was know at the time about the shortcomings of Mach specifically, or the enormous difficulty of building general-purpose multiserver microkernel operating systems in general -- still posing open research questions today...) Now perhaps your question is why we do not implement our own variant of Mach. In this case it is important to point out that we use a variant called GNU Mach, which is essentially a fork of the original Mach. In the beginning, when Mach was still an active research project, changes were kept minimal, to ease merging new official Mach releases. But as Mach is not developed upstream anymore, there is no point in that, and bigger changes have been made over the past years. Of course we could write our own Mach variant from scratch, but that would be pointless really. A clean slate is alluring -- but it's always easier in the end to start from an existing code base, no matter how old an ugly, than starting from scratch. (Having said that, one Hurd developer actually started x15mach as a totally new Mach implementation from scratch -- but stopped in the middle of it due to lack of time...) I on my part am inclined to think that the best approach towards modernizing Mach actually would be retracking the original Mach genesis: Take a modern BSD kernel, throw out all UNIX stuff, and put in the Mach stuff (IPC, external pager interface etc.) instead. Last but not least, the question might be: why not drop Mach alltogether and instead create a dedicated microkernel for the Hurd? Indeed after several failed attempts with porting to existing modern microkernels (L4, Coyotos), most of the Hurd developers seem to have arrived at the conclusion that having a microkernel specifically tailored for the Hurd's needs is the only viable option really. The experimental Viengoos kernel, which Neal created in the course of his current research work, is precisely that: an attempt to address the problems found while trying to implement the Hurd on various existing microkernels. I'm not sure whether it is better to introduce radical changes in gnumach, turning it into a completely different kernel step by step; or just move over to something entirely different in one go. 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.) -antrik-
