diff options
Diffstat (limited to 'faq/which_microkernel')
| -rw-r--r-- | faq/which_microkernel/discussion.mdwn | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/faq/which_microkernel/discussion.mdwn b/faq/which_microkernel/discussion.mdwn new file mode 100644 index 00000000..ffdc6720 --- /dev/null +++ b/faq/which_microkernel/discussion.mdwn @@ -0,0 +1,120 @@ +[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +[[!toc]] + + +# Olaf, 2011-04-10 + +This version mixes up three distinct phases: rewrite from scratch; redesign; +own microkernel. + +While Okuji initially might have intended a direct port of the existing Hurd +code, by the time I started following Hurd development (2004 IIRC), it has been +long clear that Hurd/L4 is a rewrite from scratch. + +The next phase was the desire of Neal and especially Macrus to completely +reinvent the design of the Hurd. This was mostly fueled by Shapiro's influence, +resulting in a security-above-everything rage. It was in this phase that not +only the original L4 has been abandonend, but also all thoughts about using +newer L4 variants (which might have been suitable) were forsaken in favor of +Shapiro's Coyotos. + +The whole idea of redesigning the Hurd -- especially for security concerns -- +is highly controversial: I always strongly objected to it; and Marcus later +admitted himself that he got carried away and lost sight of what really matters +for the Hurd. (But only after realising that Shapiro's notion of high security +is fundamentally incompatible with the GNU philosophy.) I opted for not +explicitely mentioning this aspect in the FAQ at all, as it's impossible to +explain properly in a compact form, and probably impossible at all to do it in +an objective fashion. + +The final phase -- following the realisation of incompatibility with +Shapiro/Coyotos -- was the attempt to create new microkernels specifically for +Hurd's needs. Marcus abandonned his pretty soon, and never made it public, so I +didn't mention it at all; but Viengoos is still relevant in certain ways. + +BTW, my original text also more explicitely answers the question what happened +to the Coyotos port -- which after all is what the title promises... + +All in all, I still think my text was better. If you have any conerns with it, +please discuss them... + + +# seL4 + +## IRC, freenode, #hurd, 2011-09-27 + + <cjuner> Does anyone remember/know if/why not seL4 was considered for + hurd-l4? Is anyone aware of any differences between seL4 and coyotos? + + +## IRC, freenode, #hurd, 2011-09-29 + + <antrik> cjuner: the seL4 project was only at the beginning when the + decision was made. so was Coyotos, but Shapiro promised back then that + building on EROS, it would be done very fast (a promise he couldn't keep + BTW); plus he convinced the people in question that it's safer to build + on his ideas... + <antrik> it doesn't really matter though, as by the time the ngHurd people + were through with Coyotos, they had already concluded that it doesn't + make sense to build upon *any* third-party microkernel + <cjuner> antrik, what was the problem with coyotos? what would be the + problem with sel4 today? + <cjuner> antrik, yes I did read the FAQ. It doesn't mention seL4 at all + (there isn't even much on the hurd-l4 mailing lists, I think that being + due to seL4 not having been released at that point?) and it does not + specify what problems they had with coyotos. + <antrik> cjuner: it doesn't? I thought it mentioned "newer L4 variants" or + something like that... but the text was rewritten a couple of times, so I + guess it got lost somewhere + <antrik> cjuner: unlike original L4, it's probably possible to implement a + system like the Hurd on top on seL4, just like on top of + Coyotos. however, foreign microkernels are always created with foreign + design ideas in mind; and building our own design around them is always + problematic. it's problematic with Mach, and it will be problematic with + any other third-party microkernel + <antrik> Coyotos specifically has different ideas about memory protection, + different ideas about task startup, different ideas about memory + handling, and different ideas about resource allocation + <cjuner> antrik, do any specific problems of the foreign designs, + specifically of seL4 or coyotos come to mind? + <antrik> cjuner: I mentioned several for Coyotos. I don't have enough + understanding of the matters to go into much more detail + <antrik> (and I suspect you don't have enough understanding of these + matters to take away anything useful from more detail ;-) ) + <antrik> I could try to explain the issues I mentioned for Coyotos (as far + as I understand them), but would that really help you? + + +# Xnu (Darwin) + + +## IRC, freenode, #hurd, 2012-03-30 + + <mel__> did people consider to port Hurd to Darwin? i.e. replace GNU Mach + with Darwin? + <braunr> no + <braunr> well, quickly only + <mel__> wouldn't it be a reasonable idea? + <mel__> after all, Darwin is production-ready and contains a Mach side. + <braunr> not more than fixing gnumach itself, or using linux instead + <mel__> well. + <braunr> those implementations have diverged with time + <mel__> i see + <mel__> the fsf should pay people for fixing gnu mach then. :) + <antrik> mel__: indeed someone consided Xnu (the actual kernel of Darwin) a + while back; but I think he shelved the idea again. not sure about the + exact reasons + <antrik> Xnu implements a few improvements that might be helpful; but it + doesn't address the really fundamental issues that matter for a true + multiserver system... |