diff options
Diffstat (limited to 'faq')
| -rw-r--r-- | faq/binary_compatibility.mdwn | 33 | ||||
| -rw-r--r-- | faq/ghamp.mdwn | 18 | ||||
| -rw-r--r-- | faq/how_many_developers.mdwn | 63 | ||||
| -rw-r--r-- | faq/how_many_developers/discussion.mdwn | 65 | ||||
| -rw-r--r-- | faq/network_transparency.mdwn | 22 | ||||
| -rw-r--r-- | faq/posix_compatibility.mdwn | 32 | ||||
| -rw-r--r-- | faq/posix_compatibility/discussion.mdwn | 25 | ||||
| -rw-r--r-- | faq/sharing_the_user_space.mdwn | 23 | ||||
| -rw-r--r-- | faq/smp.mdwn | 28 | ||||
| -rw-r--r-- | faq/system_port.mdwn | 47 | ||||
| -rw-r--r-- | faq/which_microkernel.mdwn | 55 | ||||
| -rw-r--r-- | faq/which_microkernel/discussion.mdwn | 120 |
12 files changed, 0 insertions, 531 deletions
diff --git a/faq/binary_compatibility.mdwn b/faq/binary_compatibility.mdwn deleted file mode 100644 index e9dfcdb8..00000000 --- a/faq/binary_compatibility.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -[[!meta copyright="Copyright © 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]] - -IRC, freenode, #hurd, 2012-01-13: - - <veganman> sothere's absolutelyno way,evenslowly to run i386 linuxcode - under hurd/i386? Ihave a small app, commercial, which I have to get - running there - <veganman> no source - <braunr> no way - <braunr> you'd need to create a userspace linux server catching linux - system calls and calling hurd specific stuff to implement them - <braunr> it doesn't exist, it may be hard to implement - <braunr> some cases will definitely be hard to implement - <veganman> so, no magic linux lxemu on windows? - <veganman> or linuxemu on plan9 - <pinotree> nope - <veganman> I remember somethingsilly, sonmone hadcompiled linux asauser - applicationon plan9 and inserted his own binaries as - acodeobject,toberunon plan9, for useon ibm hpc hatrdware - <veganman> it was ron minich - <veganman> 5e.iwp9.org/slides/linuxemu.pdf - <veganman> I think that was it - <veganman> google for linux & cnk for additional clues diff --git a/faq/ghamp.mdwn b/faq/ghamp.mdwn deleted file mode 100644 index 16849aff..00000000 --- a/faq/ghamp.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -[[!meta copyright="Copyright © 2010 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]]."]]"""]] - -[[!meta title="GHAMP"]] - -*GHAMP* is the GNU/Hurd-based Apache, MySQL, PHP solution stack -- analoguous -to GLAMP, which is based on GNU/Linux. - -Pronounce it like the *G* in -[GNU](http://www.gnu.org/pronunciation/pronunciation.html), followed by a -mostly silent *H*, and *AMP* as in amplifier. diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn deleted file mode 100644 index a96e0576..00000000 --- a/faq/how_many_developers.mdwn +++ /dev/null @@ -1,63 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] - -[[!meta title="How many developers are working on the GNU Hurd, and why so -few?"]] - - -# How Many Developers? - -One handful works on the core of the system in their free time, and another -handful helps with [[Debian GNU/Hurd|hurd/running/debian]] and -[[hurd/running/Arch_Hurd]] packaging. Also, an additional handful of former -developers are still available for answering technical questions, but are not -participating in the current development anymore. - -In the past (that is, a lot of years ago), the FSF did pay a few developers for -working full time on the GNU Hurd. But that was for a limited amount of time -only, and evidently, it was too little for getting the system into a -competitive state. Nowadays, it's only unpaid (apart from some -[[bounties|tag/bounty]]) and free-time volunteers' work. - -In contrast to the Linux kernel, there is no industry involvement in -development. For one, this is a good thing: independency; no conflicts of -interests. For another, it is also a bad thing: no dedicated full-time -manpower -- which matters a lot. - - -# Why So Few? - -We can only speculate. One major problem might be that the [[architectural -benefits|advantages]] are generally perceived as very abstract, with little -practical benefit. We currently don't have many tools that are actually making -use of all the possibilities. - -Another reason is that it's been taking too long. Today, most people don't -believe it will ever be ready for production use, and thus would consider -involvement a waste of time. This latter point is invalid, of course, as -learning can never be a waste of time. The same holds for the [[challenges]] -raised by the GNU Hurd -- we can only learn and improve upon working on them. - -For likely the same reasons there is no industry interest in the GNU Hurd: its -advantages are too abstract and incomplete for being of interest there. - -As for the scientific sector, the GNU Hurd projects was rather about *using* a -[[microkernel]] intead of doing research on them, for example. But, there have -been some projects and theses done, and some scientific papers published on GNU -Hurd topics, and we're generally very interested in further such projects. - - -# Attracting New Faces - -We're an open project: any interested party (*you*!) are very welcome to start -[[contributing]]. Mentoring is possible, too, to help you get started. - -Likewise, for reaching out to new developers, we're participating in [[Google's -Summer of Code program|community/gsoc]]. diff --git a/faq/how_many_developers/discussion.mdwn b/faq/how_many_developers/discussion.mdwn deleted file mode 100644 index 8e4c487a..00000000 --- a/faq/how_many_developers/discussion.mdwn +++ /dev/null @@ -1,65 +0,0 @@ -[[!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]]."]]"""]] - - -# IRC, freenode, #hurd, 2011-05-22 - - <silver_hook> Since apparently Hurd's aim is a very stable and transparent - system ...why aren't there any companies backing it up? - <antrik> silver_hook: it's not in a state yet where it would be - commercially interesting - <antrik> silver_hook: and after some epic failures in the 90s, few - companies dare to invest in microkernel development... - <silver_hook> Isn't MacOS X running on top of Mach? - <antrik> yes, but it's not a true microkernel system - <antrik> for one, it's single-server, which is boring - <antrik> also it uses co-location, i.e. runs all the system code in the - kernel address space -- they are separated only formally - <antrik> even NT is more of a microkernel system I think - <silver_hook> Oh, OK, I'm not that knowledgeable about kernels to know - that. - <antrik> well, now you know :-) - <silver_hook> Yup, thanks :) - <antrik> most people don't know this, so don't worry - <silver_hook> I was just wondering that it might be potentially an ideal - server system, right? - <antrik> well, *potentially* it might be an ideal general-purpose system, - which includes server use... though personally I think the advantages of - the architecture are more visible in desktop use, as servers tend to be - rather streamlined, with little need for individualisation :-) - <antrik> however, it still remains to be proven that true (multi-server) - microkernel operating systems actually work for general-purpose - applications... - <silver_hook> antrik: I mean regarding hosting or virtual servers. - <antrik> so far, they are only successful in the much simpler embedded - space - <antrik> well, yes, the Hurd architecture in theory allows very much - flexibility regarding virtual environments... I once blogged about - that. not sure whether server applications really require that - flexibility though. I think most people are pretty happy with the various - virtualisation/container solutions available in Linux. again, the - flexibility is more relevant in the desktop space IMHO - <antrik> dosn't mean it wouldn't be useful for servers too... just not as - much of a selling point I fear :-) - - -# IRC, freenode, #hurd, 2011-07-09 - - <antrik> gnu_srs1: regarding your question why people aren't interested in - workin on Hurd: Eric Raymond explains it pretty well in his famous - "Cathedral and Bazaar" paper - <antrik> people are more likely to work on something that *almost* works - for them, and where they only have to fill in a few missing bits - <antrik> the Hurd doesn't almost work for anyone - <antrik> actually, you should probably reread the whole paper. it's - essentially an analysis why the Hurd failed compared to Linux - - -# [[open_issues/mission_statement]] diff --git a/faq/network_transparency.mdwn b/faq/network_transparency.mdwn deleted file mode 100644 index aefaf500..00000000 --- a/faq/network_transparency.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -[[!meta copyright="Copyright © 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]] - -IRC, freenode, #hurd, 2012-01-21: - - <chromaticwt> is it possible to transfer servers running on one microkernel - on one machine, to another microkernel running on a different machine? - <chromaticwt> two machines will be running the complete os - <antrik> well, if the code for network-transparent IPC still existed, it - might be possible to move a task to another machine, while keeping the - port associations with the original system... - <antrik> if you mean actually moving it to another system, that's pretty - much impossible in any system that has stateful interfaces diff --git a/faq/posix_compatibility.mdwn b/faq/posix_compatibility.mdwn deleted file mode 100644 index 4490b7cb..00000000 --- a/faq/posix_compatibility.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011 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]]."]]"""]] - -[[!meta title="POSIX compatibility"]] - -Is it favorable of rather a hindrance to be compatible to POSIX and similar -standards? - -A lot of things in POSIX et al. are designed for [[UNIX]]-like systems with -traditional monolithic [[kernel]]s. - -Thus, a [[microkernel]]-based system, as ours is, has to employ a bunch of -detours, for example to implement the [[`fork` system call|glibc/fork]]. - -On the other hand, (mostly) complying to these standards, made a really big -body of software *just work* without any (or just trivial) [[hurd/porting]]. -Especially so for command-line programs, and libraries. - -But: a large part of today's user programs are not written according to POSIX -et al. low-level interfaces, but against GNOME, GTK+2, and other high-level -frameworks and libraries. It may be a valid option to enrich these instead of -striving for total POSIX compliance -- and the high-level programs (that is, -their users) may not even notice this, but we would avoid a lot of overhead -that comes with wrapping the [[Hurd interfaces|hurd/interface]] to be POSIX -compliant. diff --git a/faq/posix_compatibility/discussion.mdwn b/faq/posix_compatibility/discussion.mdwn deleted file mode 100644 index 0d722c9e..00000000 --- a/faq/posix_compatibility/discussion.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2011 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]] - -\#hurd IRC channel on Freenode, 2010-12-21: - - <antrik> tschwinge: the writeup ignores the fact that POSIX compatibility - is not only for applications, but also for users familiar with the UNIX - environment - <antrik> also, I still don't buy the fact that most software is not written - for POSIX. even if assuming that GNOME programs don't use POSIX (which is - only half true), there is a lot of other software in a system that is - just as important, though less visible - <antrik> (server software, startup system, device management, automation, - ...) - <antrik> tschwinge: BTW, I meant to (and partially did) write a blog - article on this topic -- but I didn't get around to finish it... diff --git a/faq/sharing_the_user_space.mdwn b/faq/sharing_the_user_space.mdwn deleted file mode 100644 index ec880827..00000000 --- a/faq/sharing_the_user_space.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -[[!meta copyright="Copyright © 2010 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]]."]]"""]] - -*Question:* Could it be possible to have a system installation where you can -dual-boot using either the [[Linux]] kernel, or the GNU Hurd, so that -everything but the kernel is shared? - -*Answer:* Given that both Linux and GNU Hurd are using the [[ELF]] binary -format, this could indeed be made possible, if all programs agreed to rely on -only one abstraction layer, for example the standard C library ([[glibc]]). -(Additionally, for example for [[system call]]s that are not covered by glibc -calls, you'd need to be able to reliably trap and emulate these.) However, -Linux' and the GNU Hurd's [[ABI]]'s have sufficiently diverged, so that this is -not easy to do. That's why you can't currently install a system in this way, -but you need a separate installation of the userspace suited for the Linux -kernel, or the GNU Hurd. diff --git a/faq/smp.mdwn b/faq/smp.mdwn deleted file mode 100644 index e95edcd2..00000000 --- a/faq/smp.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -[[!meta copyright="Copyright © 2009, 2011 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]]."]]"""]] - -[[!meta title="Does GNU/Hurd support SMP/Multicore?"]] - -The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following. - -[[microkernel/Mach]] used to be running on SMP boxes like the [[!wikipedia -Intel_iPSC/860]], so principally has the required infrastructure. It has -however not yet been enhanced to support nowadays' SMP standards like ACPI, -etc. Also, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue -code likely isn't SMP-safe. As this glue code layer is not used in the -[[microkernel/mach/gnumach/ports/Xen]] port of GNU Mach, the plan is to try it -in this enviroment first. - -[[!tag open_issue_gnumach open_issue_xen]] - -That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type). - -Once this issue is solved, there are follow-up issues about -[[open_issues/multiprocessing]] and [[open_issues/multithreading]]. diff --git a/faq/system_port.mdwn b/faq/system_port.mdwn deleted file mode 100644 index c831c36f..00000000 --- a/faq/system_port.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -[[!meta copyright="Copyright © 2011 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]]."]]"""]] - -[[!meta title="Doing a GNU/Hurd System Port"]] - -How difficult is it to port the GNU/Hurd system to run on another architecture? - -The GNU/Hurd system consists of [[/Hurd]] servers running as user-space -processes on top of the [[GNU Mach|microkernel/mach/gnumach]] microkernel. The -system functionality is usually accessed through the -[[POSIX|posix_compatibility]] interface that is provided by [[/glibc]] and -[[/libpthread]]. - -A whole-system port involves touching all these components, with varying -degree, of course. - -For a CPU architecture port, the microkernel is the most involved part, -followed by glibc and the threading library. - -The original [[microkernel/Mach]] microkernel was portable to a number of -architectures which were a lot more popular at the beginning of the 1990s than -they are now. - -The GNU/Hurd system is currently available for the x86 architecture. This -includes emulators such as [[hurd/running/QEMU]] (or KVM), or -[[hurd/running/VirtualBox]]. Besides this, there is a port for the [[Xen -domU|microkernel/mach/gnumach/ports/xen]] *sub-architecture*. - -Further on, there are some [[unfinished porting -attempts|microkernel/mach/gnumach/ports]] for the Alpha, MIPS and PowerPC -architectures. These have not been completed due to little developer interest. - -Another option is to do the port at a different layer: port the Hurd servers to -not run on the GNU Mach microkernel, but instead on top of [[another -microkernel|which_microkernel]]. Or, even by providing a Mach emulation layer -on top of a monolithic kernel. For example, there could be a port for [[having -Mach run as a POSIX user-space process|open_issues/mach_on_top_of_posix]], or -by implementing the [[Mach IPC|microkernel/mach/ipc]] facility (as well as -several others) as Linux kernel modules. While there have been some -experiments, no such port has been completed yet. diff --git a/faq/which_microkernel.mdwn b/faq/which_microkernel.mdwn deleted file mode 100644 index 84b661e4..00000000 --- a/faq/which_microkernel.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -[[!meta copyright="Copyright © 2009, 2011 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]]."]]"""]] - -[[!meta title="What happened with the Hurd ports to the L4 / Coyotos / Viengoos -microkernels?"]] - -<!-- This page shares some text with history/port_to_another_microkernel. --> - -It is a frequently asked question, which microkernel the Hurd should be based -upon assuming that [[microkernel/Mach]] is no longer considered state of the -art, and it is well known that there has been a lot of discussion about this -topic, and also some code produced, but then, years later, the Hurd is still -based on [[GNU Mach|microkernel/mach/gnumach]]. - -Around the turn of the millenium, some of the Hurd developers began -experimenting with using other [[microkernel]]s for the Hurd, as they have been -encountering a number of fundamental design issues with the [[Mach -microkernel|microkernel/mach]], mostly with respect to -[[open_issues/resource_management_problems]]. - -At that time, L4 (Pistachio) was the prime candidate. A reimplementation of -the Hurd on this microkernel looked promising, and got pretty far (running some -simple POSIX programs, such as `banner`). However, over time some lingering -design issues turned out to be fundamental problems: the original L4 is not -suitable for building object-capability systems like the Hurd. Thus -development was aborted in 2005. - -During that process, Neal Walfield and Marcus Brinkmann started on a period of -research on other microkernels, getting in deeper contact with other -researchers. There was a lot of discussion, and a lot of good ideas produced, -but a straight-forward port of the Hurd to such a modern microkernel (Coyotos, -or the new L4 variants, for example) didn't seem feasible to them anymore: they -found microkernel design and system design to be interconnected in very -intricate ways, and this demanded design changes in the Hurd's core itself. - -Based on this experience, the next step was to write an own microkernel -instead, which Neal Walfield began doing with his experimental -[[microkernel/Viengoos]] project, for his research on resource management. -Currently he works in another research area though, and thus Viengoos is on -hold. - -Note that while none of the microkernel research work is active now, the -previous experiments already yielded a lot of experience, which will be very -useful in the further development / improvement of the mainline (Mach-based) -Hurd implementation. - -For more details about this topic, please see our history page about the -[[history/port_to_another_microkernel]]. diff --git a/faq/which_microkernel/discussion.mdwn b/faq/which_microkernel/discussion.mdwn deleted file mode 100644 index ffdc6720..00000000 --- a/faq/which_microkernel/discussion.mdwn +++ /dev/null @@ -1,120 +0,0 @@ -[[!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... |