From 1b21d156dd420089325c0905f3814d0e12987f90 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 5 Nov 2008 09:37:40 +0100 Subject: Remove old redirection pages. All URLs will change nevertheless. --- hurd/gettinghelp.mdwn | 11 ----------- hurd/running/creating_image_tarball.mdwn | 11 ----------- 2 files changed, 22 deletions(-) delete mode 100644 hurd/gettinghelp.mdwn delete mode 100644 hurd/running/creating_image_tarball.mdwn (limited to 'hurd') diff --git a/hurd/gettinghelp.mdwn b/hurd/gettinghelp.mdwn deleted file mode 100644 index 1faa94c5..00000000 --- a/hurd/gettinghelp.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -[[meta copyright="Copyright © 2007, 2008 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 redir=getting_help]] diff --git a/hurd/running/creating_image_tarball.mdwn b/hurd/running/creating_image_tarball.mdwn deleted file mode 100644 index 2938c79a..00000000 --- a/hurd/running/creating_image_tarball.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -[[meta copyright="Copyright © 2008 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 redir=debian/creating_image_tarball]] -- cgit v1.2.3 From 3e4d6668e36b252069b452259ac4a82279484dae Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 5 Nov 2008 10:59:09 +0100 Subject: asking_questions: New file. Fill it with content from three pages and inline it there. --- asking_questions.mdwn | 23 +++++++++++++++++++++++ hurd/getting_help.mdwn | 7 +------ irc.mdwn | 7 +------ mailing_lists.mdwn | 6 +----- 4 files changed, 26 insertions(+), 17 deletions(-) create mode 100644 asking_questions.mdwn (limited to 'hurd') diff --git a/asking_questions.mdwn b/asking_questions.mdwn new file mode 100644 index 00000000..d58dee61 --- /dev/null +++ b/asking_questions.mdwn @@ -0,0 +1,23 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +Before asking a question, first make an effort to find the answer to your +question. A lot of questions have been asked and answered before, so please +spend some time trying to solve the problem on your own (e.g., [search the +web](http://google.com/), search these web pages, etc.), and show us that you +did so when you ask your question. + +When asking, (1) be details, and (2) demonstrate that you have made an effort, +e.g., "I am having trouble frobbing the foo. I searched the web and only found +information regarding how to frob a bar, but that seems unrelated." Provide as +many relevant details as possible reproducing them as exactly as possible. + +Also consider these +[guidelines](http://catb.org/~esr/faqs/smart-questions.html). diff --git a/hurd/getting_help.mdwn b/hurd/getting_help.mdwn index 540dc851..342410dd 100644 --- a/hurd/getting_help.mdwn +++ b/hurd/getting_help.mdwn @@ -15,12 +15,7 @@ is included in the section entitled # Forums -Please follow these [guidelines](http://catb.org/~esr/faqs/smart-questions.html) -when asking your question. Namely: spend some time trying -to solve the problem on your own (e.g., [search the web](http://www.google.com), -use this wiki, etc.), show us that you did so when you -ask your question, and provide as many relevant details as possible -reproducing them as exactly as possible. +[[inline pages=asking_questions raw=yes feeds=no]] * [[Mailing_lists]] * [[IRC]] diff --git a/irc.mdwn b/irc.mdwn index 6e97c7df..8ed9ef52 100644 --- a/irc.mdwn +++ b/irc.mdwn @@ -6,12 +6,7 @@ respect the below guidelines if you want to participate. # Asking Questions -Please follow these [guidelines](http://catb.org/~esr/faqs/smart-questions.html) -when asking your question. Namely: spend some time trying -to solve the problem on your own (e.g., [search the web](http://www.google.com), -use this wiki, etc.), show us that you did so when you -ask your question, and provide as many relevant details as possible -reproducing them as exactly as possible. +[[inline pages=asking_questions raw=yes feeds=no]] # Staying On-Topic diff --git a/mailing_lists.mdwn b/mailing_lists.mdwn index 66ae1f58..9f16c341 100644 --- a/mailing_lists.mdwn +++ b/mailing_lists.mdwn @@ -1,10 +1,6 @@ # On Posting -Before asking a question on a list, first make an effort to find the answer -to your question. When you ask your question, (1) be details, and (2) demonstrate -that you have made an effort, e.g., "I am having trouble frobbing the foo. I -searched the web and only found information regarding how to frob a bar, but -that seems unrelated." +[[inline pages=asking_questions raw=yes feeds=no]] List etiquette is to cc the sender and anyone **actively** involved in the discussion. Some people don't like this and they set their reply-to header -- cgit v1.2.3 From 8ec282ed60ae9f4b4462f6452d455f0850197993 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 5 Nov 2008 11:02:28 +0100 Subject: This is no longer only a wiki, but will be the official pages. --- colophon.mdwn | 8 ++++++++ contributing.mdwn | 6 +++--- contributing/web_pages.mdwn | 18 ++++++++---------- hurd/logo.mdwn | 2 +- index.mdwn | 19 ++++++++----------- index/discussion.mdwn | 3 ++- logo.png | Bin 17674 -> 0 bytes mailing_lists.mdwn | 2 +- render_locally | 4 ++-- 9 files changed, 33 insertions(+), 29 deletions(-) delete mode 100644 logo.png (limited to 'hurd') diff --git a/colophon.mdwn b/colophon.mdwn index a48849a9..d9b771a9 100644 --- a/colophon.mdwn +++ b/colophon.mdwn @@ -41,3 +41,11 @@ started adding content. On 2007-08-12 [[Thomas_Schwinge|tschwinge]] finished the conversion of the TWiki content to [ikiwiki](http://ikiwiki.info). Read [[about_the_twiki_to_ikiwiki_conversion]]. + + +--- + +# Rev. III + +In November 2008, [[Thomas_Schwinge|tschwinge]] imported the Hurd's current web +pages into this repository and made this the official GNU Hurd web appearance. diff --git a/contributing.mdwn b/contributing.mdwn index 8b38655f..4b731065 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -38,7 +38,7 @@ meant when people are talking about GNU/Hurd systems. This system has mostly been designed and implemented [in the '90s](http://www.gnu.org/software/hurd/history.html). It works and is usable. -For example, this wiki system [is running on a GNU/Hurd +For example, these web pages are rendered on a [GNU/Hurd system](http://www.bddebian.com/cgi-bin/uptime). You can try it out for yourself: for getting access, installing @@ -62,7 +62,7 @@ system, e.g., [[microkernels_for_beginners|microkernel/for_beginners]]. Until you can do the basic exercises listed there, you won't be able to significantly contribute to the Hurd. -For more reading resources, please see this whole wiki, and also +For more reading resources, please see these web pages, and also , for links to a bunch of documents, and in general. @@ -109,7 +109,7 @@ project. If you're interested in contributing in this area, knowing the *Hurd on Mach* system nevertheless is a prerequisite. At least have a deep look at the documentation pointers given in the previous section. Also read through the -[[HurdNG|hurd/ng]] section of this wiki. +[[HurdNG|hurd/ng]] section. Please send email to the [[mailing_lists/l4-hurd]] mailing list for discussing this post-Mach system design. diff --git a/contributing/web_pages.mdwn b/contributing/web_pages.mdwn index 45abeecc..4dc2e27c 100644 --- a/contributing/web_pages.mdwn +++ b/contributing/web_pages.mdwn @@ -16,7 +16,7 @@ projects: * Install your changes *early* and *often*: don't hold your contribution back until you think it is perfect. -Before doing any changes, you are encouraged to play a bit in this wiki's +Before doing any changes, you are encouraged to play a bit in the [[sandbox]], to become familiar with the [[ikiwiki/Markdown]] syntax. Get some [[help_on_formatting|ikiwiki/formatting]]. @@ -27,12 +27,10 @@ Feel free to ask questions or report problems on every page's [[discussion]] sub-page. They're reachable from the *Discussion* link on the top of the page, which will, when selected, create a new page if there isn't one yet. -Every page on the site is editable. Feel free to join in, but we do have some -simple requests. In an ideal wiki, everyone is equal and shares equal rights, -liberties, responsibilities and common sense. Please try to match the *tone* -of your topics and edits with the existing topics. If we all pull in the same -direction the site will be more useful for everyone, especially for our own -use. +Every page on the site is editable, like in a wiki. Feel free to join in, but +we do have some simple requests. Please try to match the *tone* of your topics +and edits with the existing topics. If we all pull in the same direction these +pages will be more useful for everyone, especially for our own use. # Edit Via the Web Interface @@ -40,7 +38,7 @@ use. When you found a page you want to work on, just follow the *Edit* link on the top of the page. When doing this for the first time, this will first transfer you to a page where you have to create a wiki account. After logging in, you -can edit the wiki pages. +can edit the pages. # Working on a Checkout of the git Repository @@ -122,14 +120,14 @@ personal working copy. You'll finally have to explicitly install your changes into the master repository, see below. -You can also locally get the whole wiki rendered to html pages: +You can also locally get the whole set of pages rendered to HTML: $ wiki/render_locally [...] scanning contributing/web_pages.mdwn rendering contributing/web_pages.mdwn - Now open `wiki.rendered/index.html' to browse the wiki pages. + Now open `wiki.rendered/index.html' to browse the pages. If you like what you've done, then it's now time to publish your changes. diff --git a/hurd/logo.mdwn b/hurd/logo.mdwn index b1030e50..fcfe22dd 100644 --- a/hurd/logo.mdwn +++ b/hurd/logo.mdwn @@ -20,6 +20,6 @@ sources](http://www.gnu.org/graphics/hurd.mf) to [[img boxes-redrawn.png]] -This symbol is also being used as a favicon for this whole wiki. +This symbol is also being used as a favicon for this web site. [[img /favicon.ico]] diff --git a/index.mdwn b/index.mdwn index c9d02976..410bf301 100644 --- a/index.mdwn +++ b/index.mdwn @@ -9,9 +9,7 @@ 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]]."]]"""]] -[[img logo.png alt="[] HURD-Wiki"]] - -Welcome to the **new** GNU Hurd wiki! +Welcome to the GNU Hurd! **There is a huge bunch of unpolished stuff on here, please help us to tidy things up!** Comments about how that could be tackled are best posted onto @@ -72,9 +70,9 @@ Find more information about it at the There are [[various_possibilities|hurd/running]] of running a GNU/Hurd system. -And this wiki is living proof of the usability of the Hurd, as it is served by a -Debian GNU/Hurd system. More people using GNU in production can be found on -[[Hurd/WhoRunsGNU]]. +And these web pages are a living proof of the usability of the Hurd, as they +are rendered on a Debian GNU/Hurd system. More people using GNU Hurd in +production can be found on [[Hurd/WhoRunsGNU]]. ## What is the Hurd? @@ -121,9 +119,8 @@ Functional systems are installable in a dual-boot configuration. Development systems are currently mostly based on the [[Debian_GNU/Hurd|hurd/running/debian]] port sponsored by the [Debian project](http://www.debian.org/). -Community resources for related projects focus around the official website -, this site at , the -[[mailing_lists]] and the [[IRC_channels|IRC]]. +Community resources for related projects focus around these pages, +, the [[mailing_lists]] and the [[IRC_channels|IRC]]. If you want to see the current discussions in the Hurd project, please have a look at the [bug-hurd mailinglist archives](http://lists.gnu.org/pipermail/bug-hurd/). @@ -134,11 +131,11 @@ the [bug-hurd mailinglist archives](http://lists.gnu.org/pipermail/bug-hurd/). ## How is this site arranged? The menu on the upper right corner provides a rough structuring about the -available content. Just follow those topics and explore the wiki. +available content. Just follow those topics and explore these pages. Further information about this site and how it was created can be found in the [[colophon]]. ---- -This wiki is powered by [ikiwiki](http://ikiwiki.info/). +These pages are powered by [ikiwiki](http://ikiwiki.info/). diff --git a/index/discussion.mdwn b/index/discussion.mdwn index aec8711d..9d40f011 100644 --- a/index/discussion.mdwn +++ b/index/discussion.mdwn @@ -10,7 +10,8 @@ is included in the section entitled # TODO -Please add your comments here about what you think needs to be done on the wiki. +Please add your comments here about what you think needs to be done on these +web pages. ## What to Add diff --git a/logo.png b/logo.png deleted file mode 100644 index 2090f9db..00000000 Binary files a/logo.png and /dev/null differ diff --git a/mailing_lists.mdwn b/mailing_lists.mdwn index 9f16c341..130178a8 100644 --- a/mailing_lists.mdwn +++ b/mailing_lists.mdwn @@ -62,7 +62,7 @@ Hurd-specific questions; for users of the Hurd. -Discussion of the website and this wiki. +Discussion of the web site. ## l4-hurd diff --git a/render_locally b/render_locally index 67c96fdb..e1c27748 100755 --- a/render_locally +++ b/render_locally @@ -15,7 +15,7 @@ dest=$src.rendered && ikiwiki \ --verbose \ - --wikiname GNU\ Hurd\ wiki \ + --wikiname GNU\ Hurd \ --templatedir "$src"/.templates \ --userdir user \ --no-usedirs \ @@ -33,4 +33,4 @@ ikiwiki \ "$src" "$dest" && echo && -echo Now\ open\ \`"$dest"/index.html\'' to browse the wiki pages.' +echo Now\ open\ \`"$dest"/index.html\'' to browse the web pages.' -- cgit v1.2.3 From 1025353771167067d3a6f8eca98ee3e7ece44be1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 5 Nov 2008 12:29:44 +0100 Subject: Unify perhaps a thousand paragraphs stating what *the Hurd* is. Hurd/TheGnuHurd -> hurd/what_is_the_gnu_hurd hurd/faq/gramatically_speaking -> hurd/what_is_the_gnu_hurd/gramatically_speaking Hurd/HurdNames, hurd-name.html -> hurd/what_is_the_gnu_hurd/origin_of_the_name Etc. --- Hurd/HurdNames.mdwn | 64 --------------- Hurd/TheGnuHurd.mdwn | 30 ------- hurd-name.html | 53 ------------- hurd.html | 91 ---------------------- hurd.mdwn | 3 +- hurd/documentation.mdwn | 2 + hurd/faq/gramatically_speaking.mdwn | 42 ---------- hurd/what_is_the_gnu_hurd.mdwn | 42 ++++++++++ .../gramatically_speaking.mdwn | 52 +++++++++++++ hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn | 48 ++++++++++++ index.mdwn | 48 +++--------- old_hurd_faq.html | 12 --- sidebar.mdwn | 4 +- whatsnew.html | 68 ---------------- 14 files changed, 158 insertions(+), 401 deletions(-) delete mode 100644 Hurd/HurdNames.mdwn delete mode 100644 Hurd/TheGnuHurd.mdwn delete mode 100644 hurd-name.html delete mode 100644 hurd/faq/gramatically_speaking.mdwn create mode 100644 hurd/what_is_the_gnu_hurd.mdwn create mode 100644 hurd/what_is_the_gnu_hurd/gramatically_speaking.mdwn create mode 100644 hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn (limited to 'hurd') diff --git a/Hurd/HurdNames.mdwn b/Hurd/HurdNames.mdwn deleted file mode 100644 index 2cd05999..00000000 --- a/Hurd/HurdNames.mdwn +++ /dev/null @@ -1,64 +0,0 @@ -[[meta copyright="Copyright © 2002, 2003, 2004, 2007, 2008 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]]."]]"""]] - -[[toc ]] - -# The Acronym - -Hurd stands for "Hird of Unix Replacing Daemons." - -Hird stands for "Hurd of Interfaces Representing Depth." - - -# Origin - -[Quoting ](http://mail.gnu.org/archive/html/help-hurd/2002-10/msg00099.html) Thomas Bushnell, BSG: - -The name "Hurd" was invented by me, as an alternate spelling for the English word "herd". -"Hird" is just another alternate spelling for the same word. By the normal rules of -English orthography, they all have the same pronunciations. - - -# Spelling, Usage and Pronunication - -The Hurd has its share of linguistic debate. The subject of proper usage comes up quite often. - -We call our kernel replacement \`\`the Hurd.'' Although Thomas Bushnell, BSG states that the -word \`\`Hurd'' is an acronym; we do not treat it as such, but rather as a concrete noun. -It is widely regarded as incorrect to use the term \`\`HURD'' or \`\`H.U.R.D.'' So, to -refer to the collection of servers running on top of the microkernel, we would say, -\`\`I have upgraded to the latest version of the Hurd.'' Since the Hurd is part of -the GNU Project, we also refer to it as \`\`GNU Hurd'' which is treated as a proper noun. - -The Hurd, in conjunction with Mach, forms the core of the GNU operating system. -So, one can say \`\`I have installed GNU on my friend's new computer.'' The -Debian Project clarifies this by using the name \`\`Debian GNU/Hurd'', because -it also distributes the GNU/Linux variant of GNU. - -To pronounce the word \`\`Hurd,'' you should say the English word \`\`herd.'' This is pronounced as \`\`hɚd'' using the International Phonetic Alphabet. - -# In Other Contexts - -One contributor from Norway described two other uses of Hird. - -* "the kings men", a name given to the men accompanying the Norwegian kings at about -year 1000 and on. -This was later coined by V. Quisling when he formed a party with -nationalistic traits to denote a set of helpers promoting his agenda -of national & Nordic ideas. - -* A symbol of collaboration with the (German) enemy used in World War II. - -Perhaps unrelated: the "herd mentality" of folks is what the Hurd project -and the the GNU project in general is fighting against, and using the Hurd it is -very easy to do so, since even normal users without privileged can change things -deep inside the system - without restricting others in any way (see -[translators](http://www.debian.org/ports/hurd/hurd-doc-translator)). diff --git a/Hurd/TheGnuHurd.mdwn b/Hurd/TheGnuHurd.mdwn deleted file mode 100644 index dbd5c721..00000000 --- a/Hurd/TheGnuHurd.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -[[meta copyright="Copyright © 2001, 2002, 2007, 2008 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]]."]]"""]] - -The Hurd is GNU's replacement for the various UNIX and Linux kernels. - -The Hurd is firstly a collection of protocols formalizing how different -components may interact. The protocols are designed to reduce the mutual -[[trust]] requirements of the actors thereby permitting a more [[extensible|extensibility]] -system. These include interface definitions to manipulate files and -directories and to resolve path names. This allows any process to -implement a file system. The only requirement is that it have access -to its backing store and that the principal that started it own the -file system node to which it connects. - -The Hurd is also a set of servers that implement these protocols. -They include fie systems, network protocols and authentication. -The servers run on top of the [[microkernel/Mach]] [[microkernel]] and use -Mach's [[microkernel/mach/IPC]] mechanism to transfer information. - -The Hurd development effort is a somewhat separate project from the -Debian GNU/Hurd port. The Hurd is a component of the GNU operating -system. diff --git a/hurd-name.html b/hurd-name.html deleted file mode 100644 index 946045d1..00000000 --- a/hurd-name.html +++ /dev/null @@ -1,53 +0,0 @@ - - - -What the name Hurd means - GNU Project - Free Software Foundation (FSF) - - - -

What the name ``Hurd'' means

- [image of a Hurd Metafont Logo] (jpeg 10k) -(jpeg 20k) -no gifs due to patent problems - -

- -"Hurd" stands for "Hird of Unix-Replacing Daemons". -And, then, "Hird" stands for "Hurd of Interfaces Representing Depth". - -

- -We have here, to my knowledge, the first software to be named by a -pair of mutually recursive acronyms. - -

- ----Thomas (formerly Michael I.) Bushnell - -

- -Return to GNU's home page. -

-FSF & GNU inquiries & questions to -gnu@gnu.org. -Other ways to contact the FSF. -

-Comments on these web pages to -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved.

-Updated: - -16 Feb 1998 tower - -

- - diff --git a/hurd.html b/hurd.html index b0eb9f80..d5dcf7b9 100644 --- a/hurd.html +++ b/hurd.html @@ -1,85 +1,3 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - -
- [image of the Hurd logo] -
-[ - - - Chinese(Simplified) -| Chinese(Traditional) -| Dutch -| English -| Esperanto -| Greek -| Hebrew -| Italian -| Polish -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

-

Table of Contents

- -

-

- -

Introduction to the Hurd

-

-The GNU Hurd is the GNU project's replacement for the Unix kernel. -The Hurd is a collection of servers that run on the Mach microkernel -to implement file systems, network protocols, file access control, and -other features that are implemented by the Unix kernel or similar -kernels (such as Linux). -

-Currently, the Hurd runs on IA32 machines. The Hurd should, and -probably will, be ported to other hardware architectures or other -microkernels in the future. -

Advantages of the Hurd

The Hurd is not the most advanced kernel known to the planet (yet), but it does have a number of enticing features: @@ -135,15 +53,6 @@ start using and developing it. -

What the Hurd means

-According to Thomas Bushnell, BSG, the primary architect of the Hurd: -
-`Hurd' stands for `Hird of Unix-Replacing Daemons'. And, then, `Hird' -stands for `Hurd of Interfaces Representing Depth'. We have here, to -my knowledge, the first software to be named by a pair of mutually -recursive acronyms. -
-

Status of the project

The Hurd, together with the GNU Mach microkernel, the GNU C Library diff --git a/hurd.mdwn b/hurd.mdwn index 403c3df2..1577c1e5 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -4,8 +4,7 @@ # Introduction -* [[TheGnuHurd]] - A Brief Description -* [[HurdNames]] - Acronym, Origin and Usage +* [[What_Is_the_GNU_Hurd]] - A Brief Description * [[History]] * [[Logo]] * [[Status]] diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index 4d431b0b..83fb9f0a 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -8,6 +8,8 @@ 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]]."]]"""]] + * [[What_Is_the_GNU_Hurd]] + * [[FAQ]] * diff --git a/hurd/faq/gramatically_speaking.mdwn b/hurd/faq/gramatically_speaking.mdwn deleted file mode 100644 index 7aa3edac..00000000 --- a/hurd/faq/gramatically_speaking.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2008 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="Grammatically speaking, what is the Hurd?"]] - -*Hurd*, as an acronym, stands for *Hird of [[Unix]]-Replacing Daemons*. *Hird*, in -turn, stands for *Hurd of Interfaces Representing Depth*. - -We treat *Hurd* as a title rather than as a proper name: it requires an -article, as in *the Hurd*. For instance: *The ext2 filesystem is provided by -the Hurd, not by Mach.* Note that all of the following are incorrect: *Hurd*, -*HURD*, *The HURD*, and *the hurd*. - -We write *the GNU Hurd* instead of *the Hurd* when we want to emphasize that -the Hurd is a GNU package. Once this has been made clear, we usually use the -shorter form, without *GNU*. - -The whole operating system includes not only the kernel and the system servers, -but also many more programs. This system is called *GNU*, or *the GNU -operating system*. The GNU programs can also run on other operating system -kernels. We say *GNU/Hurd* when we want to put emphasis on the fact that this -is the GNU system running on top of the Hurd, and to contrast it with the -GNU/Linux system which is GNU using Linux as the kernel. - -Finally, there is *Debian GNU/Hurd*. This refers to the distribution of the GNU -system as created by the Debian developers. For example: *What do you run on -your laptop? Debian GNU/Hurd, of course.* - -The French generally write *le Hurd*--that is, they treat the name as masculine -singular, capitalized as in English. - -When we are referring to the microkernel, we say *Mach* and use it as a proper -noun. For example: *Mach uses the device drivers found in version 2.0.x of -Linux.* We sometimes say *the Mach microkernel* instead of just *Mach*. diff --git a/hurd/what_is_the_gnu_hurd.mdwn b/hurd/what_is_the_gnu_hurd.mdwn new file mode 100644 index 00000000..b125fc48 --- /dev/null +++ b/hurd/what_is_the_gnu_hurd.mdwn @@ -0,0 +1,42 @@ +[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2007, 2008 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 Is the GNU Hurd?"]] + +The Hurd is the GNU project's replacement for the [[Unix]] kernel. + +The Hurd is firstly a collection of protocols formalizing how different +components may interact. The protocols are designed to reduce the mutual +[[trust]] requirements of the actors thereby permitting a more +[[extensible|extensibility]] system. These include interface definitions to +manipulate files and directories and to resolve path names. This allows any +process to implement a file system. The only requirement is that it have +access to its backing store and that the [[principal]] that started it own the +file system node to which it connects. + +The Hurd is also a set of servers that implement these protocols. +They include file systems, network protocols and authentication. +The servers run on top of the [[microkernel/Mach]] [[microkernel]] and use +Mach's [[microkernel/mach/IPC]] mechanism to transfer information. + +The Hurd supplies the last major software component needed for a complete +[[GNU_operating_system|running/gnu]] as originally conceived by Richard +M. Stallman (RMS) in 1983. The GNU vision directly drove the creation and has +guided the evolution of the [Free Software Foundation](http://fsf.org/), the +organization that is the home of the [GNU project](http://gnu.org/gnu/). + +The Hurd development effort is a somewhat separate project from the +[[Debian_GNU/Hurd|hurd/running/debian]] port. + + +Read about what the GNU Hurd is [[gramatically_speaking]]. + +Read about the [[origin_of_the_name]]. diff --git a/hurd/what_is_the_gnu_hurd/gramatically_speaking.mdwn b/hurd/what_is_the_gnu_hurd/gramatically_speaking.mdwn new file mode 100644 index 00000000..d5322693 --- /dev/null +++ b/hurd/what_is_the_gnu_hurd/gramatically_speaking.mdwn @@ -0,0 +1,52 @@ +[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2008 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="Grammatically speaking..."]] + +> *Hurd*, as an acronym, stands for *Hird of [[Unix]]-Replacing Daemons*. +> *Hird*, in turn, stands for *Hurd of Interfaces Representing Depth*. + +The Hurd has its share of linguistic debate. The subject of proper usage comes +up quite often. + +Although [[Thomas_Bushnell_states|origin_of_the_name]] that the word *Hurd* is +an acronym; we do not treat it as such, but rather as a concrete noun. We +treat *Hurd* as a title rather than as a proper name: it requires an article, +as in *the Hurd*. For instance: *The ext2 filesystem is provided by the Hurd, +not by Mach.* Note that all of the following are incorrect: *Hurd*, *HURD*, +*H.U.R.D.*, *The HURD*, and *the hurd*. + +Since the Hurd is part of the GNU Project, we also refer to it as *GNU Hurd* +which is treated as a proper noun. We write *the GNU Hurd* instead of *the +Hurd* when we want to emphasize that the Hurd is a GNU package. Once this has +been made clear, we usually use the shorter form, without *GNU*. + +The whole operating system includes not only the kernel and the system servers, +but also many more programs. This system is called *GNU*, or *the GNU +operating system*. The GNU programs can also run on other operating system +kernels. We say *GNU/Hurd* when we want to put emphasis on the fact that this +is the GNU system running on top of the Hurd, and to contrast it with the +GNU/Linux system which is GNU using Linux as the kernel. + +Finally, there is *Debian GNU/Hurd*. This refers to the distribution of the GNU +system as created by the Debian developers. For example: *What do you run on +your laptop? Debian GNU/Hurd, of course.* + +The French generally write *le Hurd*--that is, they treat the name as masculine +singular, capitalized as in English. + +When we are referring to the microkernel, we say *Mach* and use it as a proper +noun. For example: *Mach uses the device drivers found in version 2.0.x of +Linux.* We sometimes say *the Mach microkernel* instead of just *Mach*. + + +To pronounce the word *Hurd*, you should say the English word *herd*. This is +pronounced as *hÉšd* using the International Phonetic Alphabet. diff --git a/hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn b/hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn new file mode 100644 index 00000000..677f100d --- /dev/null +++ b/hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn @@ -0,0 +1,48 @@ +[[meta copyright="Copyright © 1996, 1997, 1998, 2002, 2003, 2004, 2007, 2008 +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="Origin of the Name"]] + + + +According to Thomas Bushnell, the primary architect of the Hurd: + +> *Hurd*, as an acronym, stands for *Hird of [[Unix]]-Replacing Daemons*. +> *Hird*, in turn, stands for *Hurd of Interfaces Representing Depth*. + +> We have here, to my knowledge, the first software to be named by a pair of +> mutually recursive acronyms. + +[Quoting](http://mail.gnu.org/archive/html/help-hurd/2002-10/msg00099.html) +him further: + +> The name *Hurd* was invented by me, as an alternate spelling for the English +> word *herd*. *Hird* is just another alternate spelling for the same word. +> By the [[normal_rules_of_English_orthography|gramatically_speaking]], they +> all have the same pronunciations. + + +--- + + + +In other contexts: + +One contributor from Norway described two other uses of Hird. + + * "the kings men", a name given to the men accompanying the Norwegian kings at about + year 1000 and on. + + This was later coined by V. Quisling when he formed a party with + nationalistic traits to denote a set of helpers promoting his agenda of + national and Nordic ideas. + + * a symbol of collaboration with the (German) enemy used in World War II. diff --git a/index.mdwn b/index.mdwn index 410bf301..2d4dc61d 100644 --- a/index.mdwn +++ b/index.mdwn @@ -1,5 +1,5 @@ -[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2007, 2008 Free -Software Foundation, Inc."]] +[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 +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 @@ -9,7 +9,15 @@ 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]]."]]"""]] -Welcome to the GNU Hurd! +What Is the GNU Hurd? + +The GNU Hurd is the GNU project's replacement for the Unix kernel. +The Hurd is a collection of servers that run on the Mach microkernel +to implement file systems, network protocols, file access control, and +other features that are implemented by the Unix kernel or similar +kernels (such as Linux). *[[Read_on.|hurd/what_is_the_gnu_hurd]]* + +--- **There is a huge bunch of unpolished stuff on here, please help us to tidy things up!** Comments about how that could be tackled are best posted onto @@ -74,40 +82,6 @@ And these web pages are a living proof of the usability of the Hurd, as they are rendered on a Debian GNU/Hurd system. More people using GNU Hurd in production can be found on [[Hurd/WhoRunsGNU]]. -## What is the Hurd? - -The [[Hurd]] is GNU's replacement for the various UNIX and Linux kernels. - -The Hurd is firstly a collection of protocols formalizing how different -components may interact. The protocols are designed to reduce the mutual -[[trust]] requirements of the actors thereby permitting a more -[[extensible|Extensibility]] system. These include interface definitions -to manipulate files and directories and to resolve path names. This allows -any process to implement a file system. The only requirement is that it -have access to its backing store and that the principal that started it -own the file system node to which it connects. - -The Hurd is also a set of servers that implement these protocols. The -servers run on top of [[microkernel/Mach]] and use Mach's -[[microkernel/mach/IPC]] mechanism to transfer information. - -The word *Hurd* is commonly used to refer to one of the following: - - * the Hurd software that runs on top of a [[microkernel]] (most precisely) - * a machine running the [[Debian_GNU/Hurd|hurd/running/debian]] distribution - * the [GNU Hurd](http://hurd.gnu.org/) project including related dependent - projects - * HIRD of UNIX Replacing Daemons (arguably) - * HIRD is an acronym for HURD Interfaces Representing Depth (arguably) - -The [[Hurd]] supplies the last major software component needed for a complete -[[GNU]] operating system as originally conceived by Richard M. Stallman (RMS) -in 1983. The GNU vision directly drove the creation and has guided the -evolution of the [Free Software Foundation](http://www.fsf.org/), the -organization that is the home of the [GNU project](http://www.gnu.org/gnu/). - -[[Hurd/HurdNames]] - ## Current Status diff --git a/old_hurd_faq.html b/old_hurd_faq.html index b310824b..8162184d 100644 --- a/old_hurd_faq.html +++ b/old_hurd_faq.html @@ -23,7 +23,6 @@ Original Document by: Derek Upham Contents: Q0. Where can I get the Unofficial GNU Hurd FAQ? -Q1. What is the Hurd? Q2. Where can I get a copy? Q3. Why bother writing a new OS when we have Linux and 386/BSD? Q4. What's all this about Mach 3.0 (and Mach 4.0)? @@ -52,17 +51,6 @@ You should receive a PGP-signed copy of the current version of this document in a matter of minutes. -Q1. What is the Hurd? - -The Hurd is the high-level operating system for GNU. It is currently -under development. GNU was designed as a replacement for Unix, so the -Hurd is multi-tasking and multi-user, POSIX-compliant, and will have -networking and X-windows and all that good stuff. - -Hurd is an acronym for ``Hird of Unix-Replacing Daemons''. Hird, in -turn, is an acronym for ``Hurd of Interfaces Representing Depth''. - - Q2. Where can I get a copy? To put it simply, you can't. It is still under development (by diff --git a/sidebar.mdwn b/sidebar.mdwn index 88723432..0ac0561c 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -8,7 +8,8 @@ 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]]."]]"""]] -[[img hurd/logo/boxes-redrawn.png link=/hurd/logo]] +Welcome to... [[img hurd/logo/boxes-redrawn.png link=/hurd/logo]] ... the GNU +Hurd! * **[[Home|/index]]** * **[[Community]]** @@ -18,7 +19,6 @@ is included in the section entitled --- * **[[Hurd]]**[[if test="destpage(hurd*)" then=" - * *[[About|Hurd/TheGnuHurd]]* * *[[Hurd/Documentation]]* * *[[hurd/Running]]*"]] * **[[microkernel/Mach]]**[[if test="destpage(microkernel/mach*)" then=" diff --git a/whatsnew.html b/whatsnew.html index 7f2540ac..6c6a3340 100644 --- a/whatsnew.html +++ b/whatsnew.html @@ -1,71 +1,3 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - Dutch -| English -| Esperanto -| German -| Hebrew -| Polish -| Slovak -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

What is the GNU Hurd?

-

-The GNU Hurd is the GNU project's replacement for the Unix kernel. -The Hurd is a collection of servers that run on the Mach microkernel -to implement file systems, network protocols, file access control, and -other features that are implemented by the Unix kernel or similar -kernels (such as Linux). -

-If you have any news related to the Hurd project, feel free to send a -news entry to web-hurd@gnu.org -so that it can be added here. -

What's new?

-- cgit v1.2.3 From 9e633eb9e5bdeb91103ed75e49355dfc30b1d39d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 5 Nov 2008 12:52:55 +0100 Subject: hurd.html -> hurd/status and hurd/advantages --- hurd.html | 133 ------------------------------------------------ hurd.mdwn | 1 + hurd/advantages.mdwn | 60 ++++++++++++++++++++++ hurd/documentation.mdwn | 2 + hurd/status.mdwn | 37 ++++++++++++-- 5 files changed, 95 insertions(+), 138 deletions(-) delete mode 100644 hurd.html create mode 100644 hurd/advantages.mdwn (limited to 'hurd') diff --git a/hurd.html b/hurd.html deleted file mode 100644 index d5dcf7b9..00000000 --- a/hurd.html +++ /dev/null @@ -1,133 +0,0 @@ -

Advantages of the Hurd

-The Hurd is not the most advanced kernel known to the planet (yet), -but it does have a number of enticing features: -
-
it's free software
-
-Anybody can use, modify, and redistribute it under the terms of the -GNU General Public License (GPL).
-
it's compatible
-
-The Hurd provides a familiar programming and user environment. For -all intents and purposes, the Hurd is a modern Unix-like kernel. The -Hurd uses the GNU C Library, -whose development closely tracks standards such as ANSI/ISO, BSD, -POSIX, Single Unix, SVID, and X/Open. -
-
it's built to survive
-
-Unlike other popular kernel software, the Hurd has an object-oriented -structure that allows it to evolve without compromising its design. -This structure will help the Hurd undergo major redesign and -modifications without having to be entirely rewritten. -
-
it's scalable
-
-The Hurd implementation is aggressively multithreaded so that it runs -efficiently on both single processors and symmetric multiprocessors. -The Hurd interfaces are designed to allow transparent network clusters -(collectives), although this feature has not yet been -implemented. -
-
it's extensible
-
-The Hurd is an attractive platform for learning how to become a kernel -hacker or for implementing new ideas in kernel technology. Every part -of the system is designed to be modified and extended. -
-
it's stable
-
-It is possible to develop and test new Hurd kernel components without -rebooting the machine (not even accidentally). Running your own -kernel components doesn't interfere with other users, and so no -special system privileges are required. The mechanism for kernel -extensions is secure by design: it is impossible to impose your -changes upon other users unless they authorize them or you are the -system administrator. -
-
it exists
-
-The Hurd is real software that works Right Now. It is not a research -project or a proposal. You don't have to wait at all before you can -start using and developing it. -
-
- -

Status of the project

-

-The Hurd, together with the GNU Mach microkernel, the GNU C Library -and the other GNU and non-GNU programs in the GNU system, provide a -rather complete and usable operating system today. It is not ready -for production use, as there are still many bugs and missing features. -However, it should be a good base for further development and -non-critical application usage. -

-The GNU system (also called GNU/Hurd) is completely self-contained -(you can compile all parts of it using GNU itself). You can run -several instances of the Hurd in parallel, and debug even critical -servers in one Hurd instance with gdb running on another Hurd -instance. You can run the X window system, applications that use it, -and advanced server applications like the Apache webserver. -

-On the negative side, the support for character devices (like sound -cards) and other hardware is mostly missing. Although the POSIX -interface is provided, some additional interfaces like POSIX shared -memory or semaphores are still under development. -

-All this applies to the current development version, and not to the -last release (0.2). We encourage everybody who is interested to try -out the latest development version, and send feedback to the Hurd -developers. -

- -

- -[ - - - Chinese(Simplified) -| Chinese(Traditional) -| Dutch -| English -| Esperanto -| Greek -| Hebrew -| Italian -| Polish -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/hurd.mdwn b/hurd.mdwn index 1577c1e5..2805ddfc 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -5,6 +5,7 @@ # Introduction * [[What_Is_the_GNU_Hurd]] - A Brief Description +* [[Advantages]] * [[History]] * [[Logo]] * [[Status]] diff --git a/hurd/advantages.mdwn b/hurd/advantages.mdwn new file mode 100644 index 00000000..ff8c5560 --- /dev/null +++ b/hurd/advantages.mdwn @@ -0,0 +1,60 @@ +[[meta copyright="Copyright © 2001, 2002, 2008 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]]."]]"""]] + +The Hurd is not the most advanced kernel known to the planet (yet), +but it does have a number of enticing features: + + * **it's free software** + + Anybody can use, modify, and redistribute it under the terms of the + [[GNU_General_Public_License_(GPL)|GPL]] + + * **it's compatible** + + The Hurd provides a familiar programming and user environment. For all + intents and purposes, the Hurd is a modern Unix-like kernel. The Hurd uses + the [[GNU_C_Library|glibc]], whose development closely tracks standards + such as ANSI/ISO, BSD, POSIX, Single Unix, SVID, and X/Open. + + * **it's built to survive** + + Unlike other popular kernel software, the Hurd has an object-oriented + structure that allows it to evolve without compromising its design. This + structure will help the Hurd undergo major redesign and modifications + without having to be entirely rewritten. + + * **it's scalable** + + The Hurd implementation is aggressively multithreaded so that it runs + efficiently on both single processors and symmetric multiprocessors. The + Hurd interfaces are designed to allow transparent network clusters + (*collectives*), although this feature has not yet been implemented. + + * **it's extensible** + + The Hurd is an attractive platform for learning how to become a kernel + hacker or for implementing new ideas in kernel technology. Every part of + the system is designed to be modified and extended. + + * **it's stable** + + It is possible to develop and test new Hurd kernel components without + rebooting the machine (not even accidentally). Running your own kernel + components doesn't interfere with other users, and so no special system + privileges are required. The mechanism for kernel extensions is secure by + design: it is impossible to impose your changes upon other users unless + they authorize them or you are the system administrator. + + * **it exists** + + The Hurd is real software that works Right Now. It is not a research + project or a proposal. You don't have to wait at all before you can start + using and developing it. diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index 83fb9f0a..bb37a8be 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -10,6 +10,8 @@ is included in the section entitled * [[What_Is_the_GNU_Hurd]] + * [[Advantages]] + * [[FAQ]] * diff --git a/hurd/status.mdwn b/hurd/status.mdwn index a84d7c45..b4ece046 100644 --- a/hurd/status.mdwn +++ b/hurd/status.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2001, 2002, 2007, 2008 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 @@ -8,19 +9,44 @@ 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]]."]]"""]] -The Hurd team doesn't create hurd-only releases, but instead relies -on a distribution done by folks from **Debian**. +The Hurd, together with the GNU Mach microkernel, the GNU C Library +and the other GNU and non-GNU programs in the GNU system, provide a +rather complete and usable operating system today. It may not be ready +for production use, as there are still many bugs and missing features. +However, it should be a good base for further development and +non-critical application usage. + +The GNU system (also called GNU/Hurd) is completely self-contained +(you can compile all parts of it using GNU itself). You can run +several instances of the Hurd in parallel, and debug even critical +servers in one Hurd instance with gdb running on another Hurd +instance. You can run the X window system, applications that use it, +and advanced server applications like the Apache webserver. + +On the negative side, the support for character devices (like sound +cards) and other hardware is mostly missing. Although the POSIX +interface is provided, some additional interfaces like POSIX shared +memory or semaphores are still under development. + +All this applies to the current development version, and not to the +last release (0.2). We encourage everybody who is interested to try +out the latest development version, and send feedback to the Hurd +developers. + + +The Hurd team doesn't create Hurd-only releases, but instead relies +on a distribution done by folks from *Debian*. That Debian version closely tracks the progress of the Hurd (and often includes many new features), so little would be gained by creating an official pure Hurd release. -The Debian GNU/Hurd [[distribution|running/debian]] offers **livecds and qemu images** +The Debian GNU/Hurd [[distribution|running/debian]] offers *LiveCDs and QEMU images* to test-drive the Hurd in a real life system with access to about 50% of the Debian software archive. The most recent version of the Debian port at the time of writing -is **Debian GNU/Hurd K16**. +is *Debian GNU/Hurd K16*. That said, the last official release of the Hurd @@ -34,3 +60,4 @@ already expect delays; to disappoint them in this way as well would be unfortunate. Moreover, it would lessen the possibility that they would want to try the Hurd again in the future. + -- cgit v1.2.3 From ae9e4e22a7ce8b2b56e98ff1708c2e8d42eefd69 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 5 Nov 2008 14:58:33 +0100 Subject: microkernel/mach/gnumach -> microkernel/mach/gnu_mach --- community/gsoc/project_ideas.mdwn | 6 +- contributing.mdwn | 6 +- hurd/building/cross-compiling.mdwn | 2 +- hurd/getting_help.mdwn | 2 +- hurd/libstore.mdwn | 2 +- hurd/running.mdwn | 2 +- microkernel/mach.mdwn | 2 +- microkernel/mach/gnu_mach.mdwn | 30 +++ microkernel/mach/gnu_mach/boot_trace.mdwn | 222 +++++++++++++++++++++ microkernel/mach/gnu_mach/building.mdwn | 114 +++++++++++ microkernel/mach/gnu_mach/building/example.mdwn | 54 +++++ microkernel/mach/gnu_mach/debugging.mdwn | 68 +++++++ .../mach/gnu_mach/hardware_compatibility_list.mdwn | 111 +++++++++++ .../hardware_compatibility_list/discussion.mdwn | 4 + microkernel/mach/gnu_mach/open_issues.mdwn | 19 ++ microkernel/mach/gnu_mach/ports.mdwn | 15 ++ microkernel/mach/gnu_mach/ports/xen.mdwn | 84 ++++++++ microkernel/mach/gnu_mach/ports/xen/internals.mdwn | 14 ++ .../ports/xen/networking_configuration.mdwn | 105 ++++++++++ microkernel/mach/gnu_mach/projects.mdwn | 129 ++++++++++++ .../mach/gnu_mach/projects/clean_up_the_code.mdwn | 121 +++++++++++ microkernel/mach/gnu_mach/projects/gdb_stubs.mdwn | 13 ++ microkernel/mach/gnumach.mdwn | 30 --- microkernel/mach/gnumach/boot_trace.mdwn | 222 --------------------- microkernel/mach/gnumach/building.mdwn | 114 ----------- microkernel/mach/gnumach/building/example.mdwn | 54 ----- microkernel/mach/gnumach/debugging.mdwn | 68 ------- .../mach/gnumach/hardware_compatibility_list.mdwn | 111 ----------- .../hardware_compatibility_list/discussion.mdwn | 4 - microkernel/mach/gnumach/open_issues.mdwn | 19 -- microkernel/mach/gnumach/ports.mdwn | 15 -- microkernel/mach/gnumach/ports/xen.mdwn | 84 -------- microkernel/mach/gnumach/ports/xen/internals.mdwn | 14 -- .../ports/xen/networking_configuration.mdwn | 105 ---------- microkernel/mach/gnumach/projects.mdwn | 129 ------------ .../mach/gnumach/projects/clean_up_the_code.mdwn | 121 ----------- microkernel/mach/gnumach/projects/gdb_stubs.mdwn | 13 -- microkernel/mach/history.mdwn | 2 +- microkernel/mach/mig/building.mdwn | 3 +- sidebar.mdwn | 2 +- 40 files changed, 1118 insertions(+), 1117 deletions(-) create mode 100644 microkernel/mach/gnu_mach.mdwn create mode 100644 microkernel/mach/gnu_mach/boot_trace.mdwn create mode 100644 microkernel/mach/gnu_mach/building.mdwn create mode 100644 microkernel/mach/gnu_mach/building/example.mdwn create mode 100644 microkernel/mach/gnu_mach/debugging.mdwn create mode 100644 microkernel/mach/gnu_mach/hardware_compatibility_list.mdwn create mode 100644 microkernel/mach/gnu_mach/hardware_compatibility_list/discussion.mdwn create mode 100644 microkernel/mach/gnu_mach/open_issues.mdwn create mode 100644 microkernel/mach/gnu_mach/ports.mdwn create mode 100644 microkernel/mach/gnu_mach/ports/xen.mdwn create mode 100644 microkernel/mach/gnu_mach/ports/xen/internals.mdwn create mode 100644 microkernel/mach/gnu_mach/ports/xen/networking_configuration.mdwn create mode 100644 microkernel/mach/gnu_mach/projects.mdwn create mode 100644 microkernel/mach/gnu_mach/projects/clean_up_the_code.mdwn create mode 100644 microkernel/mach/gnu_mach/projects/gdb_stubs.mdwn delete mode 100644 microkernel/mach/gnumach.mdwn delete mode 100644 microkernel/mach/gnumach/boot_trace.mdwn delete mode 100644 microkernel/mach/gnumach/building.mdwn delete mode 100644 microkernel/mach/gnumach/building/example.mdwn delete mode 100644 microkernel/mach/gnumach/debugging.mdwn delete mode 100644 microkernel/mach/gnumach/hardware_compatibility_list.mdwn delete mode 100644 microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn delete mode 100644 microkernel/mach/gnumach/open_issues.mdwn delete mode 100644 microkernel/mach/gnumach/ports.mdwn delete mode 100644 microkernel/mach/gnumach/ports/xen.mdwn delete mode 100644 microkernel/mach/gnumach/ports/xen/internals.mdwn delete mode 100644 microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn delete mode 100644 microkernel/mach/gnumach/projects.mdwn delete mode 100644 microkernel/mach/gnumach/projects/clean_up_the_code.mdwn delete mode 100644 microkernel/mach/gnumach/projects/gdb_stubs.mdwn (limited to 'hurd') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index c4b665b7..8f2fe385 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -340,7 +340,7 @@ GSoC 2008. He is still working on some outstanding issues. Although a driver framework in userspace would be desirable, presently the Hurd uses kernel drivers in the microkernel, -[[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a +[[microkernel/mach/GNU_Mach]]. (And changing this would be far beyond a GSoC project...) The problem is that the drivers in GNU Mach are presently old Linux drivers @@ -590,7 +590,7 @@ pthreads. The Hurd presently has no sound support. Fixing this, [[GNU_Savannah_task 5485]], requires two steps: the first is to port some other kernel's drivers to -[[GNU_Mach|microkernel/mach/gnumach]] so we can get access to actual sound +[[microkernel/mach/GNU_Mach]] so we can get access to actual sound hardware. The second is to implement a userspace server ([[hurd/translator]]), that implements an interface on top of the kernel device that can be used by applications -- probably OSS or maybe ALSA. @@ -741,7 +741,7 @@ directories and attaching other translators. Although there are some attempts to move to a more modern microkernel alltogether, the current Hurd implementation is based on -[[GNU_Mach|microkernel/mach/gnumach]], which is only a slightly modified +[[microkernel/mach/GNU_Mach]], which is only a slightly modified variant of the original CMU [[microkernel/Mach]]. Unfortunately, Mach was created about two decades ago, and is in turn based on diff --git a/contributing.mdwn b/contributing.mdwn index 4b731065..f21a6f32 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -33,7 +33,7 @@ There are essential two kinds of Hurd system designs. ## Hurd on Mach For one there's the implementation of the *[[Hurd]] running on the -[[GNU_Mach_microkernel|microkernel/mach/gnumach]]*. This is what is commonly +[[microkernel/mach/GNU_Mach]] microkernel*. This is what is commonly meant when people are talking about GNU/Hurd systems. This system has mostly been designed and implemented [in the @@ -84,8 +84,8 @@ Here is a [[list_of_open_issues|hurd/Open_Issues]] for the [[GNU_Hurd|hurd]]. ### Open Issues: GNU Mach -Here is a [[list_of_open_issues|microkernel/mach/gnumach/Open_Issues]] for -[[GNU_Mach|microkernel/mach/gnumach]]. +Here is a [[list_of_open_issues|microkernel/mach/gnu_mach/Open_Issues]] for +[[microkernel/mach/GNU_Mach]]. ### Open Issues: GNU MIG diff --git a/hurd/building/cross-compiling.mdwn b/hurd/building/cross-compiling.mdwn index 11afc97f..31722ead 100644 --- a/hurd/building/cross-compiling.mdwn +++ b/hurd/building/cross-compiling.mdwn @@ -98,7 +98,7 @@ guarantee is given. Always the preferred version is listed first. `gcc-4_3-branch` needs. --> -* `src/gnumach`: [[GNU_Mach|microkernel/mach/gnumach]] +* `src/gnumach`: [[microkernel/mach/GNU_Mach]] * CVS `gnumach-1-branch` diff --git a/hurd/getting_help.mdwn b/hurd/getting_help.mdwn index 342410dd..c4f80ff9 100644 --- a/hurd/getting_help.mdwn +++ b/hurd/getting_help.mdwn @@ -11,7 +11,7 @@ is included in the section entitled # Essential Documentation * [[FAQ]] -* [[microkernel/mach/gnumach/Hardware_Compatibility_List]] +* [[microkernel/mach/gnu_mach/Hardware_Compatibility_List]] # Forums diff --git a/hurd/libstore.mdwn b/hurd/libstore.mdwn index ab649ebc..3de42be3 100644 --- a/hurd/libstore.mdwn +++ b/hurd/libstore.mdwn @@ -9,7 +9,7 @@ is included in the section entitled [[GNU_Free_Documentation_License|/fdl]]."]]"""]] `libstore` is more than just a thin layer between -[[GNU_Mach|microkernel/mach/gnumach]] devices (`hd0` for example) and the +[[microkernel/mach/GNU_Mach]] devices (`hd0` for example) and the device node below `/dev`... # Available Stores diff --git a/hurd/running.mdwn b/hurd/running.mdwn index 162bc9ea..78815099 100644 --- a/hurd/running.mdwn +++ b/hurd/running.mdwn @@ -9,7 +9,7 @@ is included in the section entitled [[GNU_Free_Documentation_License|/fdl]]."]]"""]] * [[Distrib]] - Distributions based on the Hurd -* [[microkernel/mach/gnumach/ports/Xen]] - In Xen +* [[microkernel/mach/gnu_mach/ports/Xen]] - In Xen * [[Live_CD]] * [[QEMU]] - In QEMU * [[vmware]] (**non-free!**) diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn index 078b531f..7e63c724 100644 --- a/microkernel/mach.mdwn +++ b/microkernel/mach.mdwn @@ -9,7 +9,7 @@ microkernel currently used by the [[Hurd]]. # Implementations -* [[GNUMach]] +* [[GNU_Mach]] * [[Mach/OskitMach]] - A Once Successor of Mach based on OSKit * [Apple's Darwin](http://developer.apple.com/darwin/) ([API](http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/index.html)) (**non-free**) diff --git a/microkernel/mach/gnu_mach.mdwn b/microkernel/mach/gnu_mach.mdwn new file mode 100644 index 00000000..d45549f5 --- /dev/null +++ b/microkernel/mach/gnu_mach.mdwn @@ -0,0 +1,30 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +GNU Mach is currently used by the GNU [[Hurd]]. + +GNU Mach remains compatible with [[Mach]] 3.0. + +The majority of GNU Mach's [[device_driver]]s are from Linux 2.0. They were +added using glue code, i.e., a Linux [[emulation]] layer in Mach. + +GNU Mach runs on x86 machines. See the +[[hardware_compatibility_list]] and information about +[[ports]] to other architectures. + + +# Development + +* [[Building]] +* [[Debugging]] +* [[Boot_Trace]] +* [[Projects]] + * [[Rules]] + * [[Open_Issues]] diff --git a/microkernel/mach/gnu_mach/boot_trace.mdwn b/microkernel/mach/gnu_mach/boot_trace.mdwn new file mode 100644 index 00000000..a08384f0 --- /dev/null +++ b/microkernel/mach/gnu_mach/boot_trace.mdwn @@ -0,0 +1,222 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +`if NCPUS > 1` stuff is not being considered so far. + + +> i386/i386at/boothdr.S: \_start + +> i386/i386at/boothdr.S: boot\_entry + +>> i386/i386at/model\_dep.c: c\_boot\_entry + +>>> i386/i386at/boothdr.S: discover\_x86\_cpu\_type + +>>> i386/i386at/model\_dep.c: i386at\_init + +>>>> i386/i386/pic.c: picinit + +>>>> i386/i386at/model\_dep.c: mem\_size\_init + +>>>> i386/intel/pmap.c: pmap\_bootstrap + +>>>> i386/i386/gdt.c: gdt\_init + +>>>> i386/i386/idt.c: idt\_init + +>>>> i386/i386at/int\_init.c: int\_init + +>>>> i386/i386/ldt.c: ldt\_init + +>>>> i386/i386/ktss.c: ktss\_init + +>>> kern/startup.c: setup\_main + +>>>> kern/debug.c: panic\_init + +>>>> kern/printf.c: printf\_init + +>>>> kern/sched\_prim.c: sched\_init + +>>>>> kern/sched\_prim.c: wait\_queue\_init + +>>>>> kern/processor.c: pset\_sys\_bootstrap + +>>>>> kern/ast.c: ast\_init + +>>>> vm/vm\_init.c: vm\_mem\_bootstrap + +>>>>> vm/vm\_resident.c: vm\_page\_bootstrap + +>>>>>> vm/vm\_resident.c: pmap\_startup + +>>>>> kern/zalloc.c: zone\_bootstrap + +>>>>> vm/vm\_object.c: vm\_object\_bootstrap + +>>>>>> vm/vm\_external.c: vm\_external\_module\_initialize + +>>>>> vm/vm\_map.c: vm\_map\_init + +>>>>> vm/vm\_kern.c: kmem\_init + +>>>>> i386/intel/pmap.c: pmap\_init + +>>>>> kern/zalloc.c: zone\_init + +>>>>> kern/kalloc.c: kalloc\_init + +>>>>> vm/vm\_fault.c: vm\_fault\_init + +>>>>> vm/vm\_resident.c: vm\_page\_module\_init + +>>>>> vm/memory\_object.c: memory\_manager\_default\_init + +>>>> ipc/ipc\_init.c: ipc\_bootstrap + +>>>>> ipc/ipc\_table.c: ipc\_table\_init + +>>>>> ipc/ipc\_notify.c: ipc\_notify\_init + +>>>>> ipc/ipc\_hash.c: ipc\_hash\_init + +>>>>> ipc/ipc\_marequest.c: ipc\_marequest\_init + +>>>> vm/vm\_init.c: vm\_mem\_init + +>>>>> vm/vm\_object.c: vm\_object\_init + +>>>> ipc/ipc\_init.c: ipc\_init + +>>>>> kern/ipc\_host.c: ipc\_host\_init + +>>>>>> kern/ipc\_host.c: ipc\_pset\_init + +>>>>>> kern/ipc\_host.c: ipc\_pset\_enable + +>>>>>> kern/ipc\_host.c: ipc\_processor\_init + +>>>> i386/intel/pmap.h: PMAP\_ACTIVATE\_KERNEL + +>>>> kern/timer.c: init\_timers + +>>>> kern/mach\_clock.c: init\_timeout + +>>>> kern/xpr.c: xprbootstrap + +>>>> kern/time\_stamp.c: timestamp\_init + +>>>> kern/mach\_clock.c: mapable\_time\_init + +>>>> i386/i386at/model\_dep.c: machine\_init + +>>>>> device/cons.c: cninit + +>>>>> i386/i386/fpu.c: init\_fpu + +>>>>> linux/dev/init/main.c: linux\_init + +>>>>>> linux/dev/arch/i386/kernel/irq.c: init\_IRQ + +>>>>>>> linux/dev/arch/i386/kernel/irq.c: reserve\_mach\_irqs + +>>>>>> linux/dev/kernel/sched.c: linux\_sched\_init + +>>>>>> linux/dev/init/main.c: calibrate\_delay + +>>>>>> linux/dev/glue/kmem.c: linux\_kmem\_init + +>>>>>> linux/src/drivers/pci/pci.c: pci\_init + +>>>>>>> linux/src/arch/i386/kernel/bios32.c: pcibios\_init + +>>>>>>> linux/src/drivers/pci/pci.c: scan\_bus + +>>>>>>> linux/src/arch/i386/kernel/bios32.c: pcibios\_fixup + +>>>>>> linux/dev/glue/net.c: linux\_net\_emulation\_init + +>>>>>> linux/dev/drivers/block/genhd.c: device\_setup + +>>>>>>> linux/dev/glue/block.c: blk\_dev\_init + +>>>>>>>> linux/src/drivers/block/ide.c: ide\_init + +>>>>>>>> linux/dev/drivers/block/floppy.c: floppy\_init + +>>>>>>> linux/src/drivers/scsi/scsi.c: scsi\_dev\_init + +>>>>>>> linux/dev/net/core/dev.c: net\_dev\_init + +>>>>>> linux/pcmcia-cs/glue/pcmcia.c: pcmcia\_init + +>>>>> i386/i386at/autoconf.c: probeio + +>>>>> i386/i386at/model\_dep.c: inittodr + +>>>>> i386/intel/pmap.c: pmap\_unmap\_page\_zero + +>>>> kern/task.c: task\_init + +>>>>> kern/syscall\_emulation.c: eml\_init + +>>>> kern/thread.c: thread\_init + +>>>>> i386/i386/pcb.c: pcb\_module\_init + +>>>>>> i386/i386/fpu.c: fpu\_module\_init + +>>>>>> i386/i386/iopb.c: iopb\_init + +>>>> kern/thread\_swap.c: swapper\_init + +>>>> kern/sched\_prim.c: recompute\_priorities + +>>>> kern/mach\_factor.c: compute\_mach\_factor + +>>>> kern/startup.c: start\_kernel\_threads + +[...] + +>>>> kern/startup.c: cpu\_launch\_first\_thread + +>>>>> i386/i386at/model\_dep.c: startrtclock + +>>>>>> i386/i386/pit.c: clkstart + +>>>>> i386/intel/pmap.h: PMAP\_ACTIVATE\_KERNEL + +>>>>> i386/i386/pcb.c: load\_context + +[...] + +> kern/startup.c: start\_kernel\_threads + +> Threads get created. + +>> kern/sched\_prim.c: idle\_thread + +>> One for each CPU. + +>> kern/thread.c: reaper\_thread + +>> kern/thread\_swap.c: swapin\_thread + +>> kern/sched\_prim.c: sched\_thread + +>> [...] + +>> kern/bootstrap.c: bootstrap\_create + +>> [...] + +>> vm\_pageout + +>> Does not return. diff --git a/microkernel/mach/gnu_mach/building.mdwn b/microkernel/mach/gnu_mach/building.mdwn new file mode 100644 index 00000000..ef0d8553 --- /dev/null +++ b/microkernel/mach/gnu_mach/building.mdwn @@ -0,0 +1,114 @@ +Additional to the following text, a further [[example]] has be posted. + + +# Building [[GNU_Mach]] from Source + +If you want to build the [[GNU_Mach]] kernel yourself instead of just using a +pre-built binary, follow these instructions. + +The unpacked source tree is around 20 MiB, and the build tree (with all drivers +enabled) is around 50 MiB. + +## Getting the Source Code + +### Developers's RCS + +See [here](http://www.gnu.org/software/hurd/gnumach-download.html#cvs). + + $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach + +(Most probably you want to get hold of the *GNU Mach 1 branch* and not the +trunk, which is also what we've done above.) + +You then have to create the automatically generatable files: + + $ ( cd gnumach && autoreconf --install ) + +### What Debian is currently using + +See [here](http://packages.debian.net/source/unstable/gnumach). + + $ apt-get source gnumach + +Please see the Debian [[running/debian/FAQ]] before using `apt-get source`. + +## Preparing for the Build + +### ... on Debian systems + +Building GNU Mach requires the *build-essential* and *fakeroot* packages, their +dependencies and additional packages that are specified by the source gnumach +package: + + # apt-get install build-essential fakeroot + # apt-get build-dep gnumach + +### ... on non-Debian systems + +Apart from the case that you only want to install GNU Mach's header files (see +below), building GNU Mach requires you to have the Mach Interface Generator +installed. See [[building_MIG|mig/building]] about how to do that, then come +back here. + +Additionally, building GNU Mach requires a C compiler, a standard C library and +your favourite flavor of awk (gawk) and GNU make. + +## Building and Installing + +### ... Debian `.deb` files + +Change into the directory with the downloaded / unpacked GNU Mach sources, e.g. + + $ cd gnumach-20050801 + +Start the build process with + + $ dpkg-buildpackage -us -uc -b -rfakeroot + +[[GNU_Mach]] is now building. To use the new kernel, you must install the +resulting `.deb` package which is located one directory above the build +directory and has a similar name as the build directory, e.g. + + # dpkg -i ../gnumach_20050801-4_hurd-i386.deb + +You can now reboot your computer and enjoy the new kernel. + +### [TODO] + +GNU Mach should be built in a separate directory: + + $ mkdir gnumach-build + $ cd gnumach-build + +Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure +it: + + $ [...]/gnumach-1-branch/configure [TODO] + +Build the kernel image: + + $ make gnumach.gz + +Optionally run the (tiny) test suite: + + $ make check + +You can then install and use `gnumach.gz`. + +[TODO.] + +### Installing only the Header Files + +GNU Mach should be built in a separate directory: + + $ mkdir gnumach-build + $ cd gnumach-build + +Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure +it: + + $ [...]/gnumach-1-branch/configure --prefix= + +Install the header files into e.g. `~/gnu/include/`: + + $ make DESTDIR=~/gnu install-data diff --git a/microkernel/mach/gnu_mach/building/example.mdwn b/microkernel/mach/gnu_mach/building/example.mdwn new file mode 100644 index 00000000..6da05c5b --- /dev/null +++ b/microkernel/mach/gnu_mach/building/example.mdwn @@ -0,0 +1,54 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +## Compiling GNU Mach microkernel + +Host development system is IBM T41 running Debian Sarge 3.1r0a GNU/Linux. + +* gcc version: 3.3.5 +* GNU sed version: 4.1.2 +* GNU make version: 3.8 +* mig version: 1.3-4 + +Obtained gnumach-1-branch sources from cvs: + + export CVS_RSH="ssh" + cvs -z3 -d:ext:anoncvs@ savannah.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach + +Obtained mig_1.3-4_i386.deb from +http://www.hadrons.org/~guillem/debian/pool/main/mig/. Installed it using dpkg: + + dpkg -i mig_1.3-4_i386.deb + +Entered into the gnumach sources and did the following for compilation: + + mkdir build + cd build + ../configure --host=i386-unknown-gnu0.2 --build=i586-pc-linux-gnu \ + --enable-kdb --enable-ide + make + +The kernel file is created in the build directory. Move it to /boot on the +testing x86 system Hurd partition. Rename it as gnumach1 and compress it: + + mv kernel gnumach1 + gzip gnumach1 + +Add a new entry on the testing machine /boot/grub/menu.lst to boot the new +kernel. + + title GNU Hurd K10 Compiled gnumach + kernel (hd0,3)/boot/gnumach1.gz root=device:hd2s4 -s + module (hd0,3)/hurd/ext2fs.static--multiboot-command-line=${kernel-command-line} \\ + --host-priv-port=${host-port} --device-master-port=${device-port} \\ + --exec-server-task=${exec-task} -T typed ${root} $(task-create)$(task-resume) + module (hd0,3)/lib/ld.so.1 /hurd/exec $(exec-task=task-create) + +Reboot into the new compiled mygnumach1.gz kernel! diff --git a/microkernel/mach/gnu_mach/debugging.mdwn b/microkernel/mach/gnu_mach/debugging.mdwn new file mode 100644 index 00000000..fa2a9d42 --- /dev/null +++ b/microkernel/mach/gnu_mach/debugging.mdwn @@ -0,0 +1,68 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +Mach has a built-in kernel debugger. +[Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). + + +When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly +[use GDB on the running +kernel](http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC36). + + +Alternatively you can use an approach like this one: add the following code +snippet to `device/ds_routines.c`'s `ds_device_open` function, right at the top +of the function, and modify the code as needed. + + void D (char *s) + { + switch (s[0] - '0') + { + case 0: + printf ("Hello from %s!\n", __FUNCTION__); + break; + case 1: + printf ("%s: Invoking task_collect_scan.\n", __FUNCTION__); + extern void task_collect_scan (void); + task_collect_scan (); + break; + default: + printf ("No idea what you want me to do.\n"); + break; + } + } + + if (name && name[0] == 'D') + D (name + 1); + +Then boot your system and do something like this: + + # devprobe D0 + Hello from D! + # devprobe D1 + D: Invoking task_collect_scan. + # devprobe D2 + No idea what you want me to do. + +This is especially useful if you need to manually trigger some stuff inside the +running kernel, as with the *D1* example. + + +If you're doing real low level debugging, you might want to put variations of +the following snipped into the code, this code will write a `#` character at +line `[LINE]`, column `[COLUMN]` on the screen: + + *((char *) 0xb8000 + 2 * ([LINE] * 80 + [COLUMN])) = '#'; + halt_cpu (); + +The call of `halt_cpu` will -- as the name suggests -- halt the system +afterwards. This might be what you want or it might not, but it is needed at +some place when running the kernel inside QEMU, as QEMU somehow decides not to +update its display buffer anymore under certain conditions. diff --git a/microkernel/mach/gnu_mach/hardware_compatibility_list.mdwn b/microkernel/mach/gnu_mach/hardware_compatibility_list.mdwn new file mode 100644 index 00000000..09882467 --- /dev/null +++ b/microkernel/mach/gnu_mach/hardware_compatibility_list.mdwn @@ -0,0 +1,111 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +# CPU Architecture + +GNU Mach current only supports the `x86` (alias `ia32` or `i386`) architecture. + +`amd64`/`ix64` should work in `32-bit` compatibility mode. However, in practice +`amd64` systems seem to be troublesome more often than not. This is probably +related to the same (chipset-related) problems we often see with recent +machines; but it seems that `amd64` ones use problematic chipsets particularily +often. So far we haven't heard of similar problems with Intel's eqivalent +`ix64` (or `EM64T` as it used to be called) -- but maybe that just means fewer +people tried running the Hurd on such machines :-) + +Support for running GNU Mach (and a complete GNU/Hurd system) in a +[Xen](http://www.cl.cam.ac.uk/research/srg/netos/xen/) `domU` (again on `x86` +only) is [[being_worked_on|ports/xen]]. + +Read about further [[ports]]. + +# Memory + +GNU Mach will use a maximum of 1 GiB of RAM. If your system has more, +the surplus will silently be ignored. (In past times, this would hinder GNU +Mach from booting at all, but this has been fixed, so you no longer need to +apply GRUB's `uppermem` directive.) + +# Video Cards + +Debian distributes a version of [X.org](http://x.org/). If your video card driver +depends on a special kernel interface such as that provided by +the `agpgart` kernel module for the Linux kernel, then your video +card will only be supported by the VESA driver. + +Using an internal i815 videocard [won't +work](http://lists.debian.org/debian-hurd/2007/12/msg00007.html) (at least when +using the specialized driver), because of [missing AGP GART support in GNU +Mach](http://lists.debian.org/debian-hurd/2007/12/msg00011.html). + +# Sound + +No sound cards are supported at this time. + +# USB 1.1/2.0 + +USB is not supported at this time. + +However, USB-type keyboards and mice may (and have been reported to) work +nevertheless, given that the hardware / BIOS is doing emulation to the +supported legacy interfaces. + +# IEEE 1394 (Firewire) + +IEEE 1394 is not supported at this time + +# Storage + +All common IDE drives should work. Some drive geometries do not work, +e.g. drives with hundreds of GiB of storage space. If you find a specific IDE +drive that does not work, make a note of the model and technical specifications +here. + +[[toggle id="SATA" text="SATA drives may work in compatibility mode."]] + + +[[toggleable id="SATA" text=""" +This is how booting a [[GNU/Hurd_system|hurd]] will typically fail if GNU Mach +couldn't connect to the hard disk, e.g., in a SATA system without IDE +compatibility mode: + + start (hd0,3)/hurd/ext2fs.static: (hd0,3)/hurd/ext2fs.static + device:hd0s4: No such device or address + +There *may* be an option in the system's BIOS setup to configure enabling such +a compatibility mode. +"""]] + +# Device Drivers + +[GNU Mach Reference Manual, +Configuration](http://www.gnu.org/software/hurd/gnumach-doc/Configuration.html) +contains a list of device drivers that are included in GNU Mach and elaborates +on the hardware devices they support. + +# User Success Reports + +These boards are known to work. Gnumach/Hurd has been installed and run on these board successfully. + +* ASUS P2B motherboard with an Intel PII 450MHz CPU with Intel Pro/100 NIC in PCI slot +* Intel SE-440BX motherboard +* VIA EPIA-M Mini-ITX motherboard with VIA Nehemiah C3 1Ghz processor. Onboard NIC (VIA Rhine) works good. +* Compaq Deskpro ENS, Pentium3 (666 MHz upgraded to 1 GHz), Intel i815 chipset, chipset integrated NIC (detected twice, but works fine with eth0; trying to access eth1 confuses the driver and makes the system unusable), Matrox Mystique 220 (PCI) graphics card. Also works with rtl8029 (NE2000 PCI) NIC when onboard NIC disabled in BIOS setup. +* Abit BX6 Rev. 2.0 with Celeron 400, after disabling "memory hole at 15MB" option in BIOS setup. (Otherwise, Mach detects only 15MiB of RAM, making Hurd run *extremely* slow and instable.) Should also work with PentiumII or Pentium3. + +# User Failure Reports + +Some people couldn't get these hardware combinations to work with Hurd. + +Note: The Debian GNU/Hurd installer actually runs on Linux, so it (almost) always works. The critical bit is booting after installation. + +* ASUS P5A motherboard and AMD K6-2 333MHz CPU - doesn't boot +* ASUS P2B-LS motherboard with an Intel PII-MMX 400 MHz CPU - this board had a defective onboard NIC (that could not be disable in BIOS) and working 3COM Etherlink III NIC in a PCI bus slot. This combination worked with GNU/Linux. The 3COM NIC is known to work with the Hurd. However, while gnumach/Hurd will boot on this system, it is confused by the defective onboard NIC and unable to use the 3COM NIC. Attempting to start networking generates a continous stream of eth0 and eth1 reset messages on the console that renders the system unusable. +* ASrock 775Twins-HDTV with a Pentium D 810 (533 MGz FSB/2600GHz core -- information no longer present on intel's site). Doesn't boot. diff --git a/microkernel/mach/gnu_mach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnu_mach/hardware_compatibility_list/discussion.mdwn new file mode 100644 index 00000000..69ca3190 --- /dev/null +++ b/microkernel/mach/gnu_mach/hardware_compatibility_list/discussion.mdwn @@ -0,0 +1,4 @@ +Further information may still be found on + +and could perhaps be incorporated into that page. +--[[tschwinge]] diff --git a/microkernel/mach/gnu_mach/open_issues.mdwn b/microkernel/mach/gnu_mach/open_issues.mdwn new file mode 100644 index 00000000..433ec3ef --- /dev/null +++ b/microkernel/mach/gnu_mach/open_issues.mdwn @@ -0,0 +1,19 @@ +[[meta copyright="Copyright © 2008 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="Open Issues"]] + +This is a dumping ground for open issues for GNU Mach. + +[[inline +pages="microkernel/mach/gnumach/open_issues/* and !*/discussion" +show=0 +actions=yes +rootpage="microkernel/mach/gnumach/open_issues" postformtext="Add a new item titled:"]] diff --git a/microkernel/mach/gnu_mach/ports.mdwn b/microkernel/mach/gnu_mach/ports.mdwn new file mode 100644 index 00000000..00cdee8c --- /dev/null +++ b/microkernel/mach/gnu_mach/ports.mdwn @@ -0,0 +1,15 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + + * x86. This is the main port. + * [PowerPC](http://www.pjbruin.dds.nl/hurd/). Is not in a usable state. + * Alpha. Was once started, but isn't in a usable state either. + + * [[Xen]] diff --git a/microkernel/mach/gnu_mach/ports/xen.mdwn b/microkernel/mach/gnu_mach/ports/xen.mdwn new file mode 100644 index 00000000..cdb4e2de --- /dev/null +++ b/microkernel/mach/gnu_mach/ports/xen.mdwn @@ -0,0 +1,84 @@ +[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] + +[[toc ]] + +## Xen dom0, PAE-disabled hypervisor + +/!\ Since GNU Mach doesn't handle PAE yet, you'll need a PAE-disabled hypervisor. + +On Debian Lenny, for example, you can install xen-hypervisor-3.2-1-i386-nonpae. + +This also means that you'll currently need a PAE-disabled `dom0`. +[[Stefan_Siegl|stesie]] is providing a PAE-disabled Linux kernel image at +. + +You can either get binaries at or build them yourself. + +- Copy `gnumach-xen` and `hurd-modules` to your dom0 /boot. +- Copy `hurd` into `/etc/xen`, edit it for fixing access to your hurd / and swap + +## GNU/Hurd system + +/!\ You need an already installed GNU/Hurd system. + +If you have a free partition, you can fdisk to type 0x83, create a filesystem using: + + sudo mke2fs -b 4096 -I 128 -o hurd /dev/sda4 + +Replace /dev/sda4 with your partition. Install and use crosshurd to setup a GNU/Hurd system on this partition. + +## /etc/xen/hurd configuration + +Here is a sample /etc/xen/hurd configuration + + kernel = "/boot/gnumach-xen" + memory = 256 + disk = ['phy:sda4,hda,w'] + extra = "root=device:hd0" + vif = [ '' ] + ramdisk = "/boot/hurd-modules" + +Suggestions about [[networking_configuration]] are available. + +If you need stable MAC addresses, use a syntax like `vif = [ +'mac=00:16:3e:XX:XX:XX, bridge=br0' ]`. + +## Running Hurd with Xen + +To run Hurd with Xen, use: + + xm create -c hurd + +and gnumach should get started. Proceed with native-install. + + export TERM=mach + ./native-install + +- If `xm` complains about networking (`vif could not be connected`), it's Xen scripts' fault, see Xen documentation for how to configure the network. The simplest way is network-bridge with fixed IPs (note that you need the bridge-utils package for this). You can also just disable networking by commenting the vif line in the config. +- If `xm` complains `Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n')`, you most probably have a PAE-enabled hypervisor, and you just need to install and boot non-PAE hypervisor and kernel. + +## Building from sources + +If you want to generate these images, first get the `gnumach-1-branch-Xen-branch` branch from gnumach CVS. +Then look for "Ugly" in `kern/bootstrap.c`, how to generate `hurd-modules` is explained there, and you'll have to fix `EXT2FS_SIZE` and `LD_SO_SIZE` by hand. +Then use + + ./configure --enable-platform=xen + make + +The current `hurd-modules` was built from the debian packages `hurd 20070606-2` and `libc0.3 2.6.1-1`. +/!\ This means that when using this image, your GNU/Hurd system also needs to be a glibc version 2.6-based one! + +--- + +[[Internals]]. + +[[GNU_Savannah_task 5468]], [[GNU_Savannah_task 6584]]. diff --git a/microkernel/mach/gnu_mach/ports/xen/internals.mdwn b/microkernel/mach/gnu_mach/ports/xen/internals.mdwn new file mode 100644 index 00000000..09e707ea --- /dev/null +++ b/microkernel/mach/gnu_mach/ports/xen/internals.mdwn @@ -0,0 +1,14 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +The port does use Xen's para-virtualized interface for device (ide, network, +etc.) access. + +[[Virtualization]]. diff --git a/microkernel/mach/gnu_mach/ports/xen/networking_configuration.mdwn b/microkernel/mach/gnu_mach/ports/xen/networking_configuration.mdwn new file mode 100644 index 00000000..71a72bac --- /dev/null +++ b/microkernel/mach/gnu_mach/ports/xen/networking_configuration.mdwn @@ -0,0 +1,105 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +[[toc ]] + +The Xen dom0 infrastructure provides for a bridged networking setup using shell +scripts to configure the bridging device properly and attach the domUs' virtual +interfaces to the bridge. However, we've [seen +problems](http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00023.html) +when using this approach, so to [solve these +issues](http://lists.gnu.org/archive/html/bug-hurd/2008-09/msg00071.html), +instead suggest the following configuration method (to achieve the same thing). + +This is for a Debian dom0. + +# */etc/network/interfaces* + +Comment out everything referencing your physical devices. Add this: + + auto br0 + iface br0 inet dhcp + bridge_ports regex (eth|vif).* noregex + +... or if you want to do the manual configuration dance: + + auto br0 + iface br0 inet static + bridge_ports regex (eth|vif).* noregex + address 192.168.10.60 + netmask 255.255.255.0 + [...] + +This needs a version of the `bridge-utils` package more recent than the current +Debian stable one ([[debbug 405215]]). (It's trivial to rebuild the `dpkg` of, +e.g., the Debian testing one on Debian stable.) + +# */etc/xen/xend-config.sxp* + +Make sure that only `(network-script network-dummy)` and `(vif-script +vif-bridge)` are activated and all other `(network-script network-WHATEVER)`, +respective `(vif-script vif-WHATEVER)` are commented out. + + +# Sample configuration files on Debian Lenny + +## /etc/xen/hurd on dom0 + + kernel = "/boot/gnumach-xen" + memory = 256 + disk = ['phy:sda5,hda,w'] + extra = "root=device:hd0" + vif = [ 'mac=00:16:3e:00:00:00, bridge=br0' ] + ramdisk = "/boot/hurd-modules" + +/dev/sda5 is an extended partition. br0 is bridge interface on dom0. + +## /etc/xen/xend-config.sxp on dom0 + + (network-script 'network-bridge netdev=br0') + (dom0-min-mem 196) + (dom0-cpus 0) + (vncpasswd '') + +## /etc/network/interfaces on dom0 + + auto br0 + iface br0 inet static + address 192.168.1.211 + network 192.168.1.0 + netmask 255.255.255.0 + broadcast 192.168.1.255 + gateway 192.168.1.1 + bridge_ports eth1 + +eth1 is the interface that is connected to the Internet on the LAN: + +## Doing settrans on domU + + settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.1.210 -g 192.168.1.1 -m 255.255.255.0 + +## /sbin/ifconfig on dom0 + + br0 Link encap:Ethernet HWaddr 00:19:d1:2e:06:33 + inet addr:192.168.1.211 Bcast:192.168.1.255 Mask:255.255.255.0 + inet6 addr: fe80::219:d1ff:fe2e:633/64 Scope:Link + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:14187 errors:0 dropped:0 overruns:0 frame:0 + TX packets:9214 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:0 + RX bytes:936563 (914.6 KiB) TX bytes:746184 (728.6 KiB) + + eth1 Link encap:Ethernet HWaddr 00:19:d1:2e:06:33 + inet6 addr: fe80::219:d1ff:fe2e:633/64 Scope:Link + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:34339 errors:0 dropped:0 overruns:0 frame:0 + TX packets:18526 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:3019251 (2.8 MiB) TX bytes:1453672 (1.3 MiB) diff --git a/microkernel/mach/gnu_mach/projects.mdwn b/microkernel/mach/gnu_mach/projects.mdwn new file mode 100644 index 00000000..9ace6270 --- /dev/null +++ b/microkernel/mach/gnu_mach/projects.mdwn @@ -0,0 +1,129 @@ +[[meta copyright="Copyright © 2005, 2006, 2007, 2008 +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]]."]]"""]] + +This page is a place to keep track of ideas about things that may be improved +in GNU Mach, so that it'll evolve to a reliable microkernel for The Hurd, both +in terms of stability and performance. If you find anything missing here, +please feel free to add a entry with a short description. + +If you want to help with any of the task (thanks!), please send a mail to +*[[mailing_lists/bug-hurd]]* stating what task you wish to work on, +so that no duplicate efforts end up. + +# Active Branches + + * `gnumach-1-branch` is the main branch. + + * `gnumach-1-branch-Xen-branch` is a branch created by Samuel Thibault for + working on a [[ports/Xen]] port. + + * `gnumach-1-branch-gdb-branch` is a branch created by Michael Casadevall for + working on [[GDB_stubs]]. + + +# Task List + + * [[Clean_up_the_code]] + + * [[Open_Issues]] + + * Update the core architecture and drivers + + * Check what NetBSD, FreeBSD and Linux do with their host specific code + (i486, PPC, Sparc, ...). And if it might be wise to take that and use + it in GNU Mach. There is no need to worry about purely internal API's, + but the external ones shouldn't require any major changes. + + * Write a list of all functions provided by the host dependant code in + GNU Mach that gets used in the non-host specific code (kernel, IPC and + VM). + + * Once we have decided what the new internal API should look like, make a + list of the new API and the old one, and try to make things as + compatible as possible, but not at the expense of anything. + + * Implement Migrating Threads + + * Migrating Threads (MT) could improve IPC performance and making easier + the work of the scheduler. For more information, check + + + * Improve the external pagers interface + + * Implement read-ahead (huge I/O improvements expected). + + * Making this interface synchronous should improve I/O performance + significantly, without (almost) any drawbacks (we also get some + advantage from MT's). + + * Implement more paging eviction policies, so they fit better with usual + behaviour of the pagers. + + * Implement resource accounting for external pagers. + + * VM + + * Put it on user level (?) + + * Clean up the mess. + + * Provide a fast way to read/write from/to a memory object. + + * Simplify/normalise the code. + + * Simplify the IPC Semantics + + * There are a lot of things in GNU Mach's IPC that we don't need. Track + down those things, and get rid of them without requiring many changes + in the Hurd (the changes will affect MiG, but that is OK). + + * Temporary mappings for Client-Server memory transfers + + * Extend Mach's IPC to provide some kind of object which can represent a + range of memory that can temporarily be mapped into the servers address + space for sending/receiving data. This would allow us to avoid + excessive memory copies. + + * Find a new way to work with unaligned memory. + + * GDB remote debugging support + + * Implement support for GDB debugging via serial line and/or network. + Maybe this can be done together with the host-specific work above. + + See [[GDB_stubs]]. + + * Make it run as a [[UNIX]]/Linux executable. + + * Neal: + + here's a fun project: port the mach interface to Linux + (e.g., via kernel modifications) + or, to posix/glibc + (mmap, some minimal ptrace, etc.) + + * From the [Hurd bits at + sourceforge.net](http://sourceforge.net/projects/hurd): + , started by John + Tobey. Last time touched in 2003. Status completely unknown. + + * [README](http://hurd.cvs.sourceforge.net/hurd/gnumach-otop/README?view=markup) + + +# Wish List + + * Interface for userspace non-critical drivers. + + * Sound Support + + * WLAN support (ipw2200) with WEP/WPA + + * ACPI support diff --git a/microkernel/mach/gnu_mach/projects/clean_up_the_code.mdwn b/microkernel/mach/gnu_mach/projects/clean_up_the_code.mdwn new file mode 100644 index 00000000..875bb8cd --- /dev/null +++ b/microkernel/mach/gnu_mach/projects/clean_up_the_code.mdwn @@ -0,0 +1,121 @@ +[[meta copyright="Copyright © 2005, 2006, 2007, 2008 + 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]]."]]"""]] + +# Restructure the tree in a sane way + +Merge `linux/src` and `linux/dev`. But only if using a sane RCS, so leave it +as-is for now. Also, a bunch of (header) files from there may probably be +discarded. + + +# Remove dead files from the GNU Mach source tree + +For *exported* files (via `make install`), the plan is to first stick some +`#error This file is scheduled for removal. Write to if you +have a reason to have it kept available.` into them, and then actually remove +them after some months. + +For some of the internal header files (containing function prototypes and the +like), it might actually be useful to use them. (And then get rid of a bunch +of `extern ...` statements in other files.) + +This following list was assembled by putting such a `#error ...` line into each +of the `gnumach-1-branch`'s header files (exported and internal; save the +`linux/` ones (only internal) for simplicity), and then trying to build GNU +Mach until this would succeed again (by removing offending `#error ...`s), and +afterwards using the set of exported files for building a cross toolchain +(again still removing offending `#error ...`s). A very crude and imprecise +method. + +So, additionally to the list given below, there may actually be a bunch of +further files (also exported ones) that serve no real value, but are being +`#include`d through one way or another. + +* [[source_gnumach-1-branch ddb/db_expr.h]] + + Currently used, but copyright violation? Rewrite? + +* [[source_gnumach-1-branch ddb/db_print.h]] + + Copyright violation? Currently unused, but could be used in principle (or + be rewritten, to avoid the copyright oddity). + +* [[source_gnumach-1-branch ddb/tr.h]] + + Copyright violation. Unused. Remove. + +* [[source_gnumach-1-branch device/dev_master.h]] + + Might be usable for SMP? Remove otherwise. + +* [[source_gnumach-1-branch i386/i386/kttd_machdep.h]] + +* [[source_gnumach-1-branch i386/i386/sched_param.h]] + +* [[source_gnumach-1-branch i386/include/mach/i386/cthreads.h]] + + Was probably once exported, but is no longer. + +* [[source_gnumach-1-branch i386/include/mach/i386/ioccom.h]] + + Exported. + +* [[source_gnumach-1-branch include/device/audio_status.h]] + + Exported. + +* [[source_gnumach-1-branch include/device/tape_status.h]] + + Exported. + +* [[source_gnumach-1-branch include/mach/alert.h]] + + Exported. + +* [[source_gnumach-1-branch include/mach/boot.h]] + + Exported. + +* [[source_gnumach-1-branch include/mach/macro_help.h]] + + Exported. + +* [[source_gnumach-1-branch include/mach/multiboot.h]] + + Exported. + +* [[source_gnumach-1-branch include/mach/profil.h]] + + Exported. + +* [[source_gnumach-1-branch include/mach/profilparam.h]] + + Exported. + +* [[source_gnumach-1-branch include/mach/exec/a.out.h]] + + Exported. + +* [[source_gnumach-1-branch include/mach_debug/pc_info.h]] + + Currently not exported, but was probably once meant to be. + +* [[source_gnumach-1-branch kern/act.h]] + +* [[source_gnumach-1-branch kern/refcount.h]] + +* [[source_gnumach-1-branch kern/shuttle.h]] + + +# Remove dead functions, variables, etc. from source files + + +# Rewrite ugly code diff --git a/microkernel/mach/gnu_mach/projects/gdb_stubs.mdwn b/microkernel/mach/gnu_mach/projects/gdb_stubs.mdwn new file mode 100644 index 00000000..9a11a82b --- /dev/null +++ b/microkernel/mach/gnu_mach/projects/gdb_stubs.mdwn @@ -0,0 +1,13 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + + * + + * [ChangeLog.gdb](http://cvs.savannah.gnu.org/viewvc/gnumach/ChangeLog.gdb?root=hurd&view=markup&pathrev=gnumach-1-branch-gdb-branch) diff --git a/microkernel/mach/gnumach.mdwn b/microkernel/mach/gnumach.mdwn deleted file mode 100644 index d45549f5..00000000 --- a/microkernel/mach/gnumach.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] - -GNU Mach is currently used by the GNU [[Hurd]]. - -GNU Mach remains compatible with [[Mach]] 3.0. - -The majority of GNU Mach's [[device_driver]]s are from Linux 2.0. They were -added using glue code, i.e., a Linux [[emulation]] layer in Mach. - -GNU Mach runs on x86 machines. See the -[[hardware_compatibility_list]] and information about -[[ports]] to other architectures. - - -# Development - -* [[Building]] -* [[Debugging]] -* [[Boot_Trace]] -* [[Projects]] - * [[Rules]] - * [[Open_Issues]] diff --git a/microkernel/mach/gnumach/boot_trace.mdwn b/microkernel/mach/gnumach/boot_trace.mdwn deleted file mode 100644 index a08384f0..00000000 --- a/microkernel/mach/gnumach/boot_trace.mdwn +++ /dev/null @@ -1,222 +0,0 @@ -[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] - -`if NCPUS > 1` stuff is not being considered so far. - - -> i386/i386at/boothdr.S: \_start - -> i386/i386at/boothdr.S: boot\_entry - ->> i386/i386at/model\_dep.c: c\_boot\_entry - ->>> i386/i386at/boothdr.S: discover\_x86\_cpu\_type - ->>> i386/i386at/model\_dep.c: i386at\_init - ->>>> i386/i386/pic.c: picinit - ->>>> i386/i386at/model\_dep.c: mem\_size\_init - ->>>> i386/intel/pmap.c: pmap\_bootstrap - ->>>> i386/i386/gdt.c: gdt\_init - ->>>> i386/i386/idt.c: idt\_init - ->>>> i386/i386at/int\_init.c: int\_init - ->>>> i386/i386/ldt.c: ldt\_init - ->>>> i386/i386/ktss.c: ktss\_init - ->>> kern/startup.c: setup\_main - ->>>> kern/debug.c: panic\_init - ->>>> kern/printf.c: printf\_init - ->>>> kern/sched\_prim.c: sched\_init - ->>>>> kern/sched\_prim.c: wait\_queue\_init - ->>>>> kern/processor.c: pset\_sys\_bootstrap - ->>>>> kern/ast.c: ast\_init - ->>>> vm/vm\_init.c: vm\_mem\_bootstrap - ->>>>> vm/vm\_resident.c: vm\_page\_bootstrap - ->>>>>> vm/vm\_resident.c: pmap\_startup - ->>>>> kern/zalloc.c: zone\_bootstrap - ->>>>> vm/vm\_object.c: vm\_object\_bootstrap - ->>>>>> vm/vm\_external.c: vm\_external\_module\_initialize - ->>>>> vm/vm\_map.c: vm\_map\_init - ->>>>> vm/vm\_kern.c: kmem\_init - ->>>>> i386/intel/pmap.c: pmap\_init - ->>>>> kern/zalloc.c: zone\_init - ->>>>> kern/kalloc.c: kalloc\_init - ->>>>> vm/vm\_fault.c: vm\_fault\_init - ->>>>> vm/vm\_resident.c: vm\_page\_module\_init - ->>>>> vm/memory\_object.c: memory\_manager\_default\_init - ->>>> ipc/ipc\_init.c: ipc\_bootstrap - ->>>>> ipc/ipc\_table.c: ipc\_table\_init - ->>>>> ipc/ipc\_notify.c: ipc\_notify\_init - ->>>>> ipc/ipc\_hash.c: ipc\_hash\_init - ->>>>> ipc/ipc\_marequest.c: ipc\_marequest\_init - ->>>> vm/vm\_init.c: vm\_mem\_init - ->>>>> vm/vm\_object.c: vm\_object\_init - ->>>> ipc/ipc\_init.c: ipc\_init - ->>>>> kern/ipc\_host.c: ipc\_host\_init - ->>>>>> kern/ipc\_host.c: ipc\_pset\_init - ->>>>>> kern/ipc\_host.c: ipc\_pset\_enable - ->>>>>> kern/ipc\_host.c: ipc\_processor\_init - ->>>> i386/intel/pmap.h: PMAP\_ACTIVATE\_KERNEL - ->>>> kern/timer.c: init\_timers - ->>>> kern/mach\_clock.c: init\_timeout - ->>>> kern/xpr.c: xprbootstrap - ->>>> kern/time\_stamp.c: timestamp\_init - ->>>> kern/mach\_clock.c: mapable\_time\_init - ->>>> i386/i386at/model\_dep.c: machine\_init - ->>>>> device/cons.c: cninit - ->>>>> i386/i386/fpu.c: init\_fpu - ->>>>> linux/dev/init/main.c: linux\_init - ->>>>>> linux/dev/arch/i386/kernel/irq.c: init\_IRQ - ->>>>>>> linux/dev/arch/i386/kernel/irq.c: reserve\_mach\_irqs - ->>>>>> linux/dev/kernel/sched.c: linux\_sched\_init - ->>>>>> linux/dev/init/main.c: calibrate\_delay - ->>>>>> linux/dev/glue/kmem.c: linux\_kmem\_init - ->>>>>> linux/src/drivers/pci/pci.c: pci\_init - ->>>>>>> linux/src/arch/i386/kernel/bios32.c: pcibios\_init - ->>>>>>> linux/src/drivers/pci/pci.c: scan\_bus - ->>>>>>> linux/src/arch/i386/kernel/bios32.c: pcibios\_fixup - ->>>>>> linux/dev/glue/net.c: linux\_net\_emulation\_init - ->>>>>> linux/dev/drivers/block/genhd.c: device\_setup - ->>>>>>> linux/dev/glue/block.c: blk\_dev\_init - ->>>>>>>> linux/src/drivers/block/ide.c: ide\_init - ->>>>>>>> linux/dev/drivers/block/floppy.c: floppy\_init - ->>>>>>> linux/src/drivers/scsi/scsi.c: scsi\_dev\_init - ->>>>>>> linux/dev/net/core/dev.c: net\_dev\_init - ->>>>>> linux/pcmcia-cs/glue/pcmcia.c: pcmcia\_init - ->>>>> i386/i386at/autoconf.c: probeio - ->>>>> i386/i386at/model\_dep.c: inittodr - ->>>>> i386/intel/pmap.c: pmap\_unmap\_page\_zero - ->>>> kern/task.c: task\_init - ->>>>> kern/syscall\_emulation.c: eml\_init - ->>>> kern/thread.c: thread\_init - ->>>>> i386/i386/pcb.c: pcb\_module\_init - ->>>>>> i386/i386/fpu.c: fpu\_module\_init - ->>>>>> i386/i386/iopb.c: iopb\_init - ->>>> kern/thread\_swap.c: swapper\_init - ->>>> kern/sched\_prim.c: recompute\_priorities - ->>>> kern/mach\_factor.c: compute\_mach\_factor - ->>>> kern/startup.c: start\_kernel\_threads - -[...] - ->>>> kern/startup.c: cpu\_launch\_first\_thread - ->>>>> i386/i386at/model\_dep.c: startrtclock - ->>>>>> i386/i386/pit.c: clkstart - ->>>>> i386/intel/pmap.h: PMAP\_ACTIVATE\_KERNEL - ->>>>> i386/i386/pcb.c: load\_context - -[...] - -> kern/startup.c: start\_kernel\_threads - -> Threads get created. - ->> kern/sched\_prim.c: idle\_thread - ->> One for each CPU. - ->> kern/thread.c: reaper\_thread - ->> kern/thread\_swap.c: swapin\_thread - ->> kern/sched\_prim.c: sched\_thread - ->> [...] - ->> kern/bootstrap.c: bootstrap\_create - ->> [...] - ->> vm\_pageout - ->> Does not return. diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn deleted file mode 100644 index 27573b64..00000000 --- a/microkernel/mach/gnumach/building.mdwn +++ /dev/null @@ -1,114 +0,0 @@ -Additional to the following text, a further [[example]] has be posted. - - -# Building [[GNUMach]] from Source - -If you want to build the [[GNUMach]] kernel yourself instead of just using a -pre-built binary, follow these instructions. - -The unpacked source tree is around 20 MiB, and the build tree (with all drivers -enabled) is around 50 MiB. - -## Getting the Source Code - -### Developers's RCS - -See [here](http://www.gnu.org/software/hurd/gnumach-download.html#cvs). - - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach - -(Most probably you want to get hold of the *GNU Mach 1 branch* and not the -trunk, which is also what we've done above.) - -You then have to create the automatically generatable files: - - $ ( cd gnumach && autoreconf --install ) - -### What Debian is currently using - -See [here](http://packages.debian.net/source/unstable/gnumach). - - $ apt-get source gnumach - -Please see the Debian [[running/debian/FAQ]] before using `apt-get source`. - -## Preparing for the Build - -### ... on Debian systems - -Building GNU Mach requires the *build-essential* and *fakeroot* packages, their -dependencies and additional packages that are specified by the source gnumach -package: - - # apt-get install build-essential fakeroot - # apt-get build-dep gnumach - -### ... on non-Debian systems - -Apart from the case that you only want to install GNU Mach's header files (see -below), building GNU Mach requires you to have the Mach Interface Generator -installed. See [[building_MIG|mig/building]] about how to do that, then come -back here. - -Additionally, building GNU Mach requires a C compiler, a standard C library and -your favourite flavor of awk (gawk) and GNU make. - -## Building and Installing - -### ... Debian `.deb` files - -Change into the directory with the downloaded / unpacked GNU Mach sources, e.g. - - $ cd gnumach-20050801 - -Start the build process with - - $ dpkg-buildpackage -us -uc -b -rfakeroot - -[[GNUMach]] is now building. To use the new kernel, you must install the -resulting `.deb` package which is located one directory above the build -directory and has a similar name as the build directory, e.g. - - # dpkg -i ../gnumach_20050801-4_hurd-i386.deb - -You can now reboot your computer and enjoy the new kernel. - -### [TODO] - -GNU Mach should be built in a separate directory: - - $ mkdir gnumach-build - $ cd gnumach-build - -Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure -it: - - $ [...]/gnumach-1-branch/configure [TODO] - -Build the kernel image: - - $ make gnumach.gz - -Optionally run the (tiny) test suite: - - $ make check - -You can then install and use `gnumach.gz`. - -[TODO.] - -### Installing only the Header Files - -GNU Mach should be built in a separate directory: - - $ mkdir gnumach-build - $ cd gnumach-build - -Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure -it: - - $ [...]/gnumach-1-branch/configure --prefix= - -Install the header files into e.g. `~/gnu/include/`: - - $ make DESTDIR=~/gnu install-data diff --git a/microkernel/mach/gnumach/building/example.mdwn b/microkernel/mach/gnumach/building/example.mdwn deleted file mode 100644 index 6da05c5b..00000000 --- a/microkernel/mach/gnumach/building/example.mdwn +++ /dev/null @@ -1,54 +0,0 @@ -[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] - -## Compiling GNU Mach microkernel - -Host development system is IBM T41 running Debian Sarge 3.1r0a GNU/Linux. - -* gcc version: 3.3.5 -* GNU sed version: 4.1.2 -* GNU make version: 3.8 -* mig version: 1.3-4 - -Obtained gnumach-1-branch sources from cvs: - - export CVS_RSH="ssh" - cvs -z3 -d:ext:anoncvs@ savannah.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach - -Obtained mig_1.3-4_i386.deb from -http://www.hadrons.org/~guillem/debian/pool/main/mig/. Installed it using dpkg: - - dpkg -i mig_1.3-4_i386.deb - -Entered into the gnumach sources and did the following for compilation: - - mkdir build - cd build - ../configure --host=i386-unknown-gnu0.2 --build=i586-pc-linux-gnu \ - --enable-kdb --enable-ide - make - -The kernel file is created in the build directory. Move it to /boot on the -testing x86 system Hurd partition. Rename it as gnumach1 and compress it: - - mv kernel gnumach1 - gzip gnumach1 - -Add a new entry on the testing machine /boot/grub/menu.lst to boot the new -kernel. - - title GNU Hurd K10 Compiled gnumach - kernel (hd0,3)/boot/gnumach1.gz root=device:hd2s4 -s - module (hd0,3)/hurd/ext2fs.static--multiboot-command-line=${kernel-command-line} \\ - --host-priv-port=${host-port} --device-master-port=${device-port} \\ - --exec-server-task=${exec-task} -T typed ${root} $(task-create)$(task-resume) - module (hd0,3)/lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -Reboot into the new compiled mygnumach1.gz kernel! diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn deleted file mode 100644 index fa2a9d42..00000000 --- a/microkernel/mach/gnumach/debugging.mdwn +++ /dev/null @@ -1,68 +0,0 @@ -[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] - -Mach has a built-in kernel debugger. -[Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). - - -When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly -[use GDB on the running -kernel](http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC36). - - -Alternatively you can use an approach like this one: add the following code -snippet to `device/ds_routines.c`'s `ds_device_open` function, right at the top -of the function, and modify the code as needed. - - void D (char *s) - { - switch (s[0] - '0') - { - case 0: - printf ("Hello from %s!\n", __FUNCTION__); - break; - case 1: - printf ("%s: Invoking task_collect_scan.\n", __FUNCTION__); - extern void task_collect_scan (void); - task_collect_scan (); - break; - default: - printf ("No idea what you want me to do.\n"); - break; - } - } - - if (name && name[0] == 'D') - D (name + 1); - -Then boot your system and do something like this: - - # devprobe D0 - Hello from D! - # devprobe D1 - D: Invoking task_collect_scan. - # devprobe D2 - No idea what you want me to do. - -This is especially useful if you need to manually trigger some stuff inside the -running kernel, as with the *D1* example. - - -If you're doing real low level debugging, you might want to put variations of -the following snipped into the code, this code will write a `#` character at -line `[LINE]`, column `[COLUMN]` on the screen: - - *((char *) 0xb8000 + 2 * ([LINE] * 80 + [COLUMN])) = '#'; - halt_cpu (); - -The call of `halt_cpu` will -- as the name suggests -- halt the system -afterwards. This might be what you want or it might not, but it is needed at -some place when running the kernel inside QEMU, as QEMU somehow decides not to -update its display buffer anymore under certain conditions. diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn deleted file mode 100644 index 09882467..00000000 --- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn +++ /dev/null @@ -1,111 +0,0 @@ -[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] - -# CPU Architecture - -GNU Mach current only supports the `x86` (alias `ia32` or `i386`) architecture. - -`amd64`/`ix64` should work in `32-bit` compatibility mode. However, in practice -`amd64` systems seem to be troublesome more often than not. This is probably -related to the same (chipset-related) problems we often see with recent -machines; but it seems that `amd64` ones use problematic chipsets particularily -often. So far we haven't heard of similar problems with Intel's eqivalent -`ix64` (or `EM64T` as it used to be called) -- but maybe that just means fewer -people tried running the Hurd on such machines :-) - -Support for running GNU Mach (and a complete GNU/Hurd system) in a -[Xen](http://www.cl.cam.ac.uk/research/srg/netos/xen/) `domU` (again on `x86` -only) is [[being_worked_on|ports/xen]]. - -Read about further [[ports]]. - -# Memory - -GNU Mach will use a maximum of 1 GiB of RAM. If your system has more, -the surplus will silently be ignored. (In past times, this would hinder GNU -Mach from booting at all, but this has been fixed, so you no longer need to -apply GRUB's `uppermem` directive.) - -# Video Cards - -Debian distributes a version of [X.org](http://x.org/). If your video card driver -depends on a special kernel interface such as that provided by -the `agpgart` kernel module for the Linux kernel, then your video -card will only be supported by the VESA driver. - -Using an internal i815 videocard [won't -work](http://lists.debian.org/debian-hurd/2007/12/msg00007.html) (at least when -using the specialized driver), because of [missing AGP GART support in GNU -Mach](http://lists.debian.org/debian-hurd/2007/12/msg00011.html). - -# Sound - -No sound cards are supported at this time. - -# USB 1.1/2.0 - -USB is not supported at this time. - -However, USB-type keyboards and mice may (and have been reported to) work -nevertheless, given that the hardware / BIOS is doing emulation to the -supported legacy interfaces. - -# IEEE 1394 (Firewire) - -IEEE 1394 is not supported at this time - -# Storage - -All common IDE drives should work. Some drive geometries do not work, -e.g. drives with hundreds of GiB of storage space. If you find a specific IDE -drive that does not work, make a note of the model and technical specifications -here. - -[[toggle id="SATA" text="SATA drives may work in compatibility mode."]] - - -[[toggleable id="SATA" text=""" -This is how booting a [[GNU/Hurd_system|hurd]] will typically fail if GNU Mach -couldn't connect to the hard disk, e.g., in a SATA system without IDE -compatibility mode: - - start (hd0,3)/hurd/ext2fs.static: (hd0,3)/hurd/ext2fs.static - device:hd0s4: No such device or address - -There *may* be an option in the system's BIOS setup to configure enabling such -a compatibility mode. -"""]] - -# Device Drivers - -[GNU Mach Reference Manual, -Configuration](http://www.gnu.org/software/hurd/gnumach-doc/Configuration.html) -contains a list of device drivers that are included in GNU Mach and elaborates -on the hardware devices they support. - -# User Success Reports - -These boards are known to work. Gnumach/Hurd has been installed and run on these board successfully. - -* ASUS P2B motherboard with an Intel PII 450MHz CPU with Intel Pro/100 NIC in PCI slot -* Intel SE-440BX motherboard -* VIA EPIA-M Mini-ITX motherboard with VIA Nehemiah C3 1Ghz processor. Onboard NIC (VIA Rhine) works good. -* Compaq Deskpro ENS, Pentium3 (666 MHz upgraded to 1 GHz), Intel i815 chipset, chipset integrated NIC (detected twice, but works fine with eth0; trying to access eth1 confuses the driver and makes the system unusable), Matrox Mystique 220 (PCI) graphics card. Also works with rtl8029 (NE2000 PCI) NIC when onboard NIC disabled in BIOS setup. -* Abit BX6 Rev. 2.0 with Celeron 400, after disabling "memory hole at 15MB" option in BIOS setup. (Otherwise, Mach detects only 15MiB of RAM, making Hurd run *extremely* slow and instable.) Should also work with PentiumII or Pentium3. - -# User Failure Reports - -Some people couldn't get these hardware combinations to work with Hurd. - -Note: The Debian GNU/Hurd installer actually runs on Linux, so it (almost) always works. The critical bit is booting after installation. - -* ASUS P5A motherboard and AMD K6-2 333MHz CPU - doesn't boot -* ASUS P2B-LS motherboard with an Intel PII-MMX 400 MHz CPU - this board had a defective onboard NIC (that could not be disable in BIOS) and working 3COM Etherlink III NIC in a PCI bus slot. This combination worked with GNU/Linux. The 3COM NIC is known to work with the Hurd. However, while gnumach/Hurd will boot on this system, it is confused by the defective onboard NIC and unable to use the 3COM NIC. Attempting to start networking generates a continous stream of eth0 and eth1 reset messages on the console that renders the system unusable. -* ASrock 775Twins-HDTV with a Pentium D 810 (533 MGz FSB/2600GHz core -- information no longer present on intel's site). Doesn't boot. diff --git a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn deleted file mode 100644 index 69ca3190..00000000 --- a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -Further information may still be found on - -and could perhaps be incorporated into that page. ---[[tschwinge]] diff --git a/microkernel/mach/gnumach/open_issues.mdwn b/microkernel/mach/gnumach/open_issues.mdwn deleted file mode 100644 index 433ec3ef..00000000 --- a/microkernel/mach/gnumach/open_issues.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -[[meta copyright="Copyright © 2008 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="Open Issues"]] - -This is a dumping ground for open issues for GNU Mach. - -[[inline -pages="microkernel/mach/gnumach/open_issues/* and !*/discussion" -show=0 -actions=yes -rootpage="microkernel/mach/gnumach/open_issues" postformtext="Add a new item titled:"]] diff --git a/microkernel/mach/gnumach/ports.mdwn b/microkernel/mach/gnumach/ports.mdwn deleted file mode 100644 index 00cdee8c..00000000 --- a/microkernel/mach/gnumach/ports.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] - - * x86. This is the main port. - * [PowerPC](http://www.pjbruin.dds.nl/hurd/). Is not in a usable state. - * Alpha. Was once started, but isn't in a usable state either. - - * [[Xen]] diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn deleted file mode 100644 index cdb4e2de..00000000 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -[[meta copyright="Copyright © 2007, 2008 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]]."]]"""]] - -[[toc ]] - -## Xen dom0, PAE-disabled hypervisor - -/!\ Since GNU Mach doesn't handle PAE yet, you'll need a PAE-disabled hypervisor. - -On Debian Lenny, for example, you can install xen-hypervisor-3.2-1-i386-nonpae. - -This also means that you'll currently need a PAE-disabled `dom0`. -[[Stefan_Siegl|stesie]] is providing a PAE-disabled Linux kernel image at -. - -You can either get binaries at or build them yourself. - -- Copy `gnumach-xen` and `hurd-modules` to your dom0 /boot. -- Copy `hurd` into `/etc/xen`, edit it for fixing access to your hurd / and swap - -## GNU/Hurd system - -/!\ You need an already installed GNU/Hurd system. - -If you have a free partition, you can fdisk to type 0x83, create a filesystem using: - - sudo mke2fs -b 4096 -I 128 -o hurd /dev/sda4 - -Replace /dev/sda4 with your partition. Install and use crosshurd to setup a GNU/Hurd system on this partition. - -## /etc/xen/hurd configuration - -Here is a sample /etc/xen/hurd configuration - - kernel = "/boot/gnumach-xen" - memory = 256 - disk = ['phy:sda4,hda,w'] - extra = "root=device:hd0" - vif = [ '' ] - ramdisk = "/boot/hurd-modules" - -Suggestions about [[networking_configuration]] are available. - -If you need stable MAC addresses, use a syntax like `vif = [ -'mac=00:16:3e:XX:XX:XX, bridge=br0' ]`. - -## Running Hurd with Xen - -To run Hurd with Xen, use: - - xm create -c hurd - -and gnumach should get started. Proceed with native-install. - - export TERM=mach - ./native-install - -- If `xm` complains about networking (`vif could not be connected`), it's Xen scripts' fault, see Xen documentation for how to configure the network. The simplest way is network-bridge with fixed IPs (note that you need the bridge-utils package for this). You can also just disable networking by commenting the vif line in the config. -- If `xm` complains `Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n')`, you most probably have a PAE-enabled hypervisor, and you just need to install and boot non-PAE hypervisor and kernel. - -## Building from sources - -If you want to generate these images, first get the `gnumach-1-branch-Xen-branch` branch from gnumach CVS. -Then look for "Ugly" in `kern/bootstrap.c`, how to generate `hurd-modules` is explained there, and you'll have to fix `EXT2FS_SIZE` and `LD_SO_SIZE` by hand. -Then use - - ./configure --enable-platform=xen - make - -The current `hurd-modules` was built from the debian packages `hurd 20070606-2` and `libc0.3 2.6.1-1`. -/!\ This means that when using this image, your GNU/Hurd system also needs to be a glibc version 2.6-based one! - ---- - -[[Internals]]. - -[[GNU_Savannah_task 5468]], [[GNU_Savannah_task 6584]]. diff --git a/microkernel/mach/gnumach/ports/xen/internals.mdwn b/microkernel/mach/gnumach/ports/xen/internals.mdwn deleted file mode 100644 index 09e707ea..00000000 --- a/microkernel/mach/gnumach/ports/xen/internals.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -[[meta copyright="Copyright © 2008 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]]."]]"""]] - -The port does use Xen's para-virtualized interface for device (ide, network, -etc.) access. - -[[Virtualization]]. diff --git a/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn b/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn deleted file mode 100644 index 71a72bac..00000000 --- a/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn +++ /dev/null @@ -1,105 +0,0 @@ -[[meta copyright="Copyright © 2008 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]]."]]"""]] - -[[toc ]] - -The Xen dom0 infrastructure provides for a bridged networking setup using shell -scripts to configure the bridging device properly and attach the domUs' virtual -interfaces to the bridge. However, we've [seen -problems](http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00023.html) -when using this approach, so to [solve these -issues](http://lists.gnu.org/archive/html/bug-hurd/2008-09/msg00071.html), -instead suggest the following configuration method (to achieve the same thing). - -This is for a Debian dom0. - -# */etc/network/interfaces* - -Comment out everything referencing your physical devices. Add this: - - auto br0 - iface br0 inet dhcp - bridge_ports regex (eth|vif).* noregex - -... or if you want to do the manual configuration dance: - - auto br0 - iface br0 inet static - bridge_ports regex (eth|vif).* noregex - address 192.168.10.60 - netmask 255.255.255.0 - [...] - -This needs a version of the `bridge-utils` package more recent than the current -Debian stable one ([[debbug 405215]]). (It's trivial to rebuild the `dpkg` of, -e.g., the Debian testing one on Debian stable.) - -# */etc/xen/xend-config.sxp* - -Make sure that only `(network-script network-dummy)` and `(vif-script -vif-bridge)` are activated and all other `(network-script network-WHATEVER)`, -respective `(vif-script vif-WHATEVER)` are commented out. - - -# Sample configuration files on Debian Lenny - -## /etc/xen/hurd on dom0 - - kernel = "/boot/gnumach-xen" - memory = 256 - disk = ['phy:sda5,hda,w'] - extra = "root=device:hd0" - vif = [ 'mac=00:16:3e:00:00:00, bridge=br0' ] - ramdisk = "/boot/hurd-modules" - -/dev/sda5 is an extended partition. br0 is bridge interface on dom0. - -## /etc/xen/xend-config.sxp on dom0 - - (network-script 'network-bridge netdev=br0') - (dom0-min-mem 196) - (dom0-cpus 0) - (vncpasswd '') - -## /etc/network/interfaces on dom0 - - auto br0 - iface br0 inet static - address 192.168.1.211 - network 192.168.1.0 - netmask 255.255.255.0 - broadcast 192.168.1.255 - gateway 192.168.1.1 - bridge_ports eth1 - -eth1 is the interface that is connected to the Internet on the LAN: - -## Doing settrans on domU - - settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.1.210 -g 192.168.1.1 -m 255.255.255.0 - -## /sbin/ifconfig on dom0 - - br0 Link encap:Ethernet HWaddr 00:19:d1:2e:06:33 - inet addr:192.168.1.211 Bcast:192.168.1.255 Mask:255.255.255.0 - inet6 addr: fe80::219:d1ff:fe2e:633/64 Scope:Link - UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 - RX packets:14187 errors:0 dropped:0 overruns:0 frame:0 - TX packets:9214 errors:0 dropped:0 overruns:0 carrier:0 - collisions:0 txqueuelen:0 - RX bytes:936563 (914.6 KiB) TX bytes:746184 (728.6 KiB) - - eth1 Link encap:Ethernet HWaddr 00:19:d1:2e:06:33 - inet6 addr: fe80::219:d1ff:fe2e:633/64 Scope:Link - UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 - RX packets:34339 errors:0 dropped:0 overruns:0 frame:0 - TX packets:18526 errors:0 dropped:0 overruns:0 carrier:0 - collisions:0 txqueuelen:1000 - RX bytes:3019251 (2.8 MiB) TX bytes:1453672 (1.3 MiB) diff --git a/microkernel/mach/gnumach/projects.mdwn b/microkernel/mach/gnumach/projects.mdwn deleted file mode 100644 index 9ace6270..00000000 --- a/microkernel/mach/gnumach/projects.mdwn +++ /dev/null @@ -1,129 +0,0 @@ -[[meta copyright="Copyright © 2005, 2006, 2007, 2008 -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]]."]]"""]] - -This page is a place to keep track of ideas about things that may be improved -in GNU Mach, so that it'll evolve to a reliable microkernel for The Hurd, both -in terms of stability and performance. If you find anything missing here, -please feel free to add a entry with a short description. - -If you want to help with any of the task (thanks!), please send a mail to -*[[mailing_lists/bug-hurd]]* stating what task you wish to work on, -so that no duplicate efforts end up. - -# Active Branches - - * `gnumach-1-branch` is the main branch. - - * `gnumach-1-branch-Xen-branch` is a branch created by Samuel Thibault for - working on a [[ports/Xen]] port. - - * `gnumach-1-branch-gdb-branch` is a branch created by Michael Casadevall for - working on [[GDB_stubs]]. - - -# Task List - - * [[Clean_up_the_code]] - - * [[Open_Issues]] - - * Update the core architecture and drivers - - * Check what NetBSD, FreeBSD and Linux do with their host specific code - (i486, PPC, Sparc, ...). And if it might be wise to take that and use - it in GNU Mach. There is no need to worry about purely internal API's, - but the external ones shouldn't require any major changes. - - * Write a list of all functions provided by the host dependant code in - GNU Mach that gets used in the non-host specific code (kernel, IPC and - VM). - - * Once we have decided what the new internal API should look like, make a - list of the new API and the old one, and try to make things as - compatible as possible, but not at the expense of anything. - - * Implement Migrating Threads - - * Migrating Threads (MT) could improve IPC performance and making easier - the work of the scheduler. For more information, check - - - * Improve the external pagers interface - - * Implement read-ahead (huge I/O improvements expected). - - * Making this interface synchronous should improve I/O performance - significantly, without (almost) any drawbacks (we also get some - advantage from MT's). - - * Implement more paging eviction policies, so they fit better with usual - behaviour of the pagers. - - * Implement resource accounting for external pagers. - - * VM - - * Put it on user level (?) - - * Clean up the mess. - - * Provide a fast way to read/write from/to a memory object. - - * Simplify/normalise the code. - - * Simplify the IPC Semantics - - * There are a lot of things in GNU Mach's IPC that we don't need. Track - down those things, and get rid of them without requiring many changes - in the Hurd (the changes will affect MiG, but that is OK). - - * Temporary mappings for Client-Server memory transfers - - * Extend Mach's IPC to provide some kind of object which can represent a - range of memory that can temporarily be mapped into the servers address - space for sending/receiving data. This would allow us to avoid - excessive memory copies. - - * Find a new way to work with unaligned memory. - - * GDB remote debugging support - - * Implement support for GDB debugging via serial line and/or network. - Maybe this can be done together with the host-specific work above. - - See [[GDB_stubs]]. - - * Make it run as a [[UNIX]]/Linux executable. - - * Neal: - - here's a fun project: port the mach interface to Linux - (e.g., via kernel modifications) - or, to posix/glibc - (mmap, some minimal ptrace, etc.) - - * From the [Hurd bits at - sourceforge.net](http://sourceforge.net/projects/hurd): - , started by John - Tobey. Last time touched in 2003. Status completely unknown. - - * [README](http://hurd.cvs.sourceforge.net/hurd/gnumach-otop/README?view=markup) - - -# Wish List - - * Interface for userspace non-critical drivers. - - * Sound Support - - * WLAN support (ipw2200) with WEP/WPA - - * ACPI support diff --git a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn deleted file mode 100644 index 875bb8cd..00000000 --- a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn +++ /dev/null @@ -1,121 +0,0 @@ -[[meta copyright="Copyright © 2005, 2006, 2007, 2008 - 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]]."]]"""]] - -# Restructure the tree in a sane way - -Merge `linux/src` and `linux/dev`. But only if using a sane RCS, so leave it -as-is for now. Also, a bunch of (header) files from there may probably be -discarded. - - -# Remove dead files from the GNU Mach source tree - -For *exported* files (via `make install`), the plan is to first stick some -`#error This file is scheduled for removal. Write to if you -have a reason to have it kept available.` into them, and then actually remove -them after some months. - -For some of the internal header files (containing function prototypes and the -like), it might actually be useful to use them. (And then get rid of a bunch -of `extern ...` statements in other files.) - -This following list was assembled by putting such a `#error ...` line into each -of the `gnumach-1-branch`'s header files (exported and internal; save the -`linux/` ones (only internal) for simplicity), and then trying to build GNU -Mach until this would succeed again (by removing offending `#error ...`s), and -afterwards using the set of exported files for building a cross toolchain -(again still removing offending `#error ...`s). A very crude and imprecise -method. - -So, additionally to the list given below, there may actually be a bunch of -further files (also exported ones) that serve no real value, but are being -`#include`d through one way or another. - -* [[source_gnumach-1-branch ddb/db_expr.h]] - - Currently used, but copyright violation? Rewrite? - -* [[source_gnumach-1-branch ddb/db_print.h]] - - Copyright violation? Currently unused, but could be used in principle (or - be rewritten, to avoid the copyright oddity). - -* [[source_gnumach-1-branch ddb/tr.h]] - - Copyright violation. Unused. Remove. - -* [[source_gnumach-1-branch device/dev_master.h]] - - Might be usable for SMP? Remove otherwise. - -* [[source_gnumach-1-branch i386/i386/kttd_machdep.h]] - -* [[source_gnumach-1-branch i386/i386/sched_param.h]] - -* [[source_gnumach-1-branch i386/include/mach/i386/cthreads.h]] - - Was probably once exported, but is no longer. - -* [[source_gnumach-1-branch i386/include/mach/i386/ioccom.h]] - - Exported. - -* [[source_gnumach-1-branch include/device/audio_status.h]] - - Exported. - -* [[source_gnumach-1-branch include/device/tape_status.h]] - - Exported. - -* [[source_gnumach-1-branch include/mach/alert.h]] - - Exported. - -* [[source_gnumach-1-branch include/mach/boot.h]] - - Exported. - -* [[source_gnumach-1-branch include/mach/macro_help.h]] - - Exported. - -* [[source_gnumach-1-branch include/mach/multiboot.h]] - - Exported. - -* [[source_gnumach-1-branch include/mach/profil.h]] - - Exported. - -* [[source_gnumach-1-branch include/mach/profilparam.h]] - - Exported. - -* [[source_gnumach-1-branch include/mach/exec/a.out.h]] - - Exported. - -* [[source_gnumach-1-branch include/mach_debug/pc_info.h]] - - Currently not exported, but was probably once meant to be. - -* [[source_gnumach-1-branch kern/act.h]] - -* [[source_gnumach-1-branch kern/refcount.h]] - -* [[source_gnumach-1-branch kern/shuttle.h]] - - -# Remove dead functions, variables, etc. from source files - - -# Rewrite ugly code diff --git a/microkernel/mach/gnumach/projects/gdb_stubs.mdwn b/microkernel/mach/gnumach/projects/gdb_stubs.mdwn deleted file mode 100644 index 9a11a82b..00000000 --- a/microkernel/mach/gnumach/projects/gdb_stubs.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -[[meta copyright="Copyright © 2008 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]]."]]"""]] - - * - - * [ChangeLog.gdb](http://cvs.savannah.gnu.org/viewvc/gnumach/ChangeLog.gdb?root=hurd&view=markup&pathrev=gnumach-1-branch-gdb-branch) diff --git a/microkernel/mach/history.mdwn b/microkernel/mach/history.mdwn index a8951737..8f4b528b 100644 --- a/microkernel/mach/history.mdwn +++ b/microkernel/mach/history.mdwn @@ -41,7 +41,7 @@ Meanwhile, OSKit became unmaintained, thus posing more of a burden on than being In 2005 Gianluca Guida started a different attempt to use the osenv interface with minimal changes to GNU Mach 1.x, thus allowing use of the generic driver interface while importing as little of the umaintained OSKit code as possible. However, there turned out to be serious problems with OSKit, so this attempt was abandoned as well. Today, GNU Mach development focuses on the 1.x branch again -- see also this -list of [[gnumach/projects]]. +list of [[gnu_mach/projects]]. # Status of the project diff --git a/microkernel/mach/mig/building.mdwn b/microkernel/mach/mig/building.mdwn index ee299166..2ec75e38 100644 --- a/microkernel/mach/mig/building.mdwn +++ b/microkernel/mach/mig/building.mdwn @@ -29,7 +29,8 @@ Building the Mach Interface Generator requires the _build-essential_ and _fakero Building the Mach Interface Generator requires a C compiler, a standard C library (with corresponding header files) and your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. -Additionally, you need to have GNU Mach's header files installed. See [[mach/gnumach/building]] about how to do that, then come back here. +Additionally, you need to have GNU Mach's header files installed. See +[[mach/gnu_mach/building]] about how to do that, then come back here. ## Building and Installing diff --git a/sidebar.mdwn b/sidebar.mdwn index 0ac0561c..a368c6c3 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -22,7 +22,7 @@ Hurd! * *[[Hurd/Documentation]]* * *[[hurd/Running]]*"]] * **[[microkernel/Mach]]**[[if test="destpage(microkernel/mach*)" then=" - * *[[GNU_Mach|microkernel/mach/gnumach]]* + * *[[microkernel/mach/GNU_Mach]]* * *[[microkernel/mach/Documentation]]*"]] --- -- cgit v1.2.3 From ddf77132bf33cd7807e9614d37dd7b3e3703a994 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 5 Nov 2008 18:54:52 +0100 Subject: Add source and align to it. --- hurd/what_is_the_gnu_hurd/gramatically_speaking.mdwn | 6 ++++-- hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn | 20 +++++++++++--------- 2 files changed, 15 insertions(+), 11 deletions(-) (limited to 'hurd') diff --git a/hurd/what_is_the_gnu_hurd/gramatically_speaking.mdwn b/hurd/what_is_the_gnu_hurd/gramatically_speaking.mdwn index d5322693..4a2ddc67 100644 --- a/hurd/what_is_the_gnu_hurd/gramatically_speaking.mdwn +++ b/hurd/what_is_the_gnu_hurd/gramatically_speaking.mdwn @@ -11,8 +11,10 @@ is included in the section entitled [[meta title="Grammatically speaking..."]] -> *Hurd*, as an acronym, stands for *Hird of [[Unix]]-Replacing Daemons*. -> *Hird*, in turn, stands for *Hurd of Interfaces Representing Depth*. +> [[It's_time_to_explain|origin_of_the_name]] the meaning of *Hurd*. +> +> *Hurd* stands for *Hird of [[Unix]]-Replacing Daemons*. +> And, then, *Hird* stands for *Hurd of Interfaces Representing Depth*. The Hurd has its share of linguistic debate. The subject of proper usage comes up quite often. diff --git a/hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn b/hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn index 677f100d..3527703a 100644 --- a/hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn +++ b/hurd/what_is_the_gnu_hurd/origin_of_the_name.mdwn @@ -11,15 +11,17 @@ is included in the section entitled [[meta title="Origin of the Name"]] - - -According to Thomas Bushnell, the primary architect of the Hurd: - -> *Hurd*, as an acronym, stands for *Hird of [[Unix]]-Replacing Daemons*. -> *Hird*, in turn, stands for *Hurd of Interfaces Representing Depth*. - -> We have here, to my knowledge, the first software to be named by a pair of -> mutually recursive acronyms. +[According to Thomas +Bushnell](http://web.cecs.pdx.edu/~trent/gnu/hurd/hurd-name), the primary +architect of the Hurd: + +> It's time to explain the meaning of *Hurd*. +> +> *Hurd* stands for *Hird of [[Unix]]-Replacing Daemons*. +> And, then, *Hird* stands for *Hurd of Interfaces Representing Depth*. +> +> We have here, to my knowledge, the first software to be named by a +> pair of mutually recursive acronyms. [Quoting](http://mail.gnu.org/archive/html/help-hurd/2002-10/msg00099.html) him further: -- cgit v1.2.3 From a9accad064758577799a0ef2fb8f6242ef815829 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 07:55:26 +0100 Subject: Remove old logos. --- hurd.mdwn | 2 -- hurd/logo.png | Bin 15125 -> 0 bytes hurd/running/debian.mdwn | 2 -- hurd/running/debian/logo.png | Bin 2463 -> 0 bytes hurd/running/gnu.mdwn | 2 -- hurd/running/gnu/gnu.mdwn | 2 -- hurd/running/gnu/logo.png | Bin 3112 -> 0 bytes microkernel/mach.mdwn | 2 -- microkernel/mach/logo.png | Bin 13617 -> 0 bytes microkernel/mach/mig.mdwn | 2 -- microkernel/mach/mig/logo.png | Bin 23622 -> 0 bytes 11 files changed, 12 deletions(-) delete mode 100644 hurd/logo.png delete mode 100644 hurd/running/debian/logo.png delete mode 100644 hurd/running/gnu/logo.png delete mode 100644 microkernel/mach/logo.png delete mode 100644 microkernel/mach/mig/logo.png (limited to 'hurd') diff --git a/hurd.mdwn b/hurd.mdwn index 2805ddfc..4bf43873 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - [[toc ]] # Introduction diff --git a/hurd/logo.png b/hurd/logo.png deleted file mode 100644 index a892b47d..00000000 Binary files a/hurd/logo.png and /dev/null differ diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index f291b75b..f80c1cfc 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -1,7 +1,5 @@ [[meta title="Debian GNU/Hurd"]] -[[img logo.png]] - - Debian [[FAQ]] -- Frequently Asked Questions - [[After_install]] -- Do this to get networking, new console and X - [Presentation](http://people.debian.org/~mbanck/talks/hurd_lt2004/html/) diff --git a/hurd/running/debian/logo.png b/hurd/running/debian/logo.png deleted file mode 100644 index 068d9584..00000000 Binary files a/hurd/running/debian/logo.png and /dev/null differ diff --git a/hurd/running/gnu.mdwn b/hurd/running/gnu.mdwn index 2ae2f2ca..26d93279 100644 --- a/hurd/running/gnu.mdwn +++ b/hurd/running/gnu.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - # The GNU Operating System The GNU Operating System, or GNU System as it is more commonly known, will be a diff --git a/hurd/running/gnu/gnu.mdwn b/hurd/running/gnu/gnu.mdwn index 2a3629d7..3ee5f657 100644 --- a/hurd/running/gnu/gnu.mdwn +++ b/hurd/running/gnu/gnu.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - ## GNU, FSF & RMS GNU stands for GNU's Not [[Unix]]. It is a project announced in 1983 by diff --git a/hurd/running/gnu/logo.png b/hurd/running/gnu/logo.png deleted file mode 100644 index 50c392cf..00000000 Binary files a/hurd/running/gnu/logo.png and /dev/null differ diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn index 7e63c724..594a74f9 100644 --- a/microkernel/mach.mdwn +++ b/microkernel/mach.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - Mach is a so-called first generation [[microkernel]]. It is the microkernel currently used by the [[Hurd]]. diff --git a/microkernel/mach/logo.png b/microkernel/mach/logo.png deleted file mode 100644 index 94951acf..00000000 Binary files a/microkernel/mach/logo.png and /dev/null differ diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn index c620420a..cf6d95bb 100644 --- a/microkernel/mach/mig.mdwn +++ b/microkernel/mach/mig.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - The Mach Interface Generator (MIG) is an [[IDL]] compiler. Based on an interface definition, it creates stubs to [[invoke]] object methods and to demultiplex incoming messages. These stubs conveniently hide diff --git a/microkernel/mach/mig/logo.png b/microkernel/mach/mig/logo.png deleted file mode 100644 index cdfec179..00000000 Binary files a/microkernel/mach/mig/logo.png and /dev/null differ -- cgit v1.2.3 From 65ad34e710723380896dd7d2d193afc62116ad89 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 08:29:26 +0100 Subject: [[microkernel/mach/mig/gnu_mig]]: New; move most content there. --- contributing.mdwn | 8 +- hurd/building/cross-compiling.mdwn | 2 +- microkernel/mach.mdwn | 2 +- microkernel/mach/gnu_mach/building.mdwn | 2 +- microkernel/mach/mig.mdwn | 12 +- microkernel/mach/mig/building.mdwn | 72 --------- microkernel/mach/mig/discussion.mdwn | 17 --- microkernel/mach/mig/gnu_mig.mdwn | 24 +++ microkernel/mach/mig/gnu_mig/building.mdwn | 73 +++++++++ microkernel/mach/mig/gnu_mig/open_issues.mdwn | 20 +++ .../open_issues/duplicate_inclusion_guards.mdwn | 14 ++ microkernel/mach/mig/open_issues.mdwn | 19 --- .../open_issues/duplicate_inclusion_guards.mdwn | 14 -- mig-download.html | 167 --------------------- mig.html | 125 --------------- sidebar.mdwn | 28 ++-- 16 files changed, 159 insertions(+), 440 deletions(-) delete mode 100644 microkernel/mach/mig/building.mdwn delete mode 100644 microkernel/mach/mig/discussion.mdwn create mode 100644 microkernel/mach/mig/gnu_mig.mdwn create mode 100644 microkernel/mach/mig/gnu_mig/building.mdwn create mode 100644 microkernel/mach/mig/gnu_mig/open_issues.mdwn create mode 100644 microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn delete mode 100644 microkernel/mach/mig/open_issues.mdwn delete mode 100644 microkernel/mach/mig/open_issues/duplicate_inclusion_guards.mdwn delete mode 100644 mig-download.html delete mode 100644 mig.html (limited to 'hurd') diff --git a/contributing.mdwn b/contributing.mdwn index f21a6f32..698d03b3 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -80,17 +80,17 @@ doesn't work or suit you and try to improve that. ### Open Issues: GNU Hurd -Here is a [[list_of_open_issues|hurd/Open_Issues]] for the [[GNU_Hurd|hurd]]. +Here is a [[list_of_open_issues|hurd/open_issues]] for the [[GNU_Hurd|hurd]]. ### Open Issues: GNU Mach -Here is a [[list_of_open_issues|microkernel/mach/gnu_mach/Open_Issues]] for +Here is a [[list_of_open_issues|microkernel/mach/gnu_mach/open_issues]] for [[microkernel/mach/GNU_Mach]]. ### Open Issues: GNU MIG -Here is a [[list_of_open_issues|microkernel/mach/mig/Open_Issues]] for -[[GNU_MIG|microkernel/mach/mig]]. +Here is a [[list_of_open_issues|microkernel/mach/mig/gnu_mig/open_issues]] for +[[microkernel/mach/mig/GNU_MIG]]. diff --git a/hurd/building/cross-compiling.mdwn b/hurd/building/cross-compiling.mdwn index 31722ead..e548c75c 100644 --- a/hurd/building/cross-compiling.mdwn +++ b/hurd/building/cross-compiling.mdwn @@ -110,7 +110,7 @@ guarantee is given. Always the preferred version is listed first. $ ( cd gnumach-1-branch/ && autoreconf -vfi ) -* `src/mig`: [[GNU_Mach_Interface_Generator|microkernel/mach/mig]] +* `src/mig`: [[microkernel/mach/mig/GNU_MIG]] * CVS `HEAD` diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn index 594a74f9..9d3289b4 100644 --- a/microkernel/mach.mdwn +++ b/microkernel/mach.mdwn @@ -13,4 +13,4 @@ microkernel currently used by the [[Hurd]]. # Related -* [[Mach_Interface_Generator|mig]] +* [[Mach_Interface_Generator_(MIG)|mig]] diff --git a/microkernel/mach/gnu_mach/building.mdwn b/microkernel/mach/gnu_mach/building.mdwn index ef0d8553..073c68a3 100644 --- a/microkernel/mach/gnu_mach/building.mdwn +++ b/microkernel/mach/gnu_mach/building.mdwn @@ -47,7 +47,7 @@ package: Apart from the case that you only want to install GNU Mach's header files (see below), building GNU Mach requires you to have the Mach Interface Generator -installed. See [[building_MIG|mig/building]] about how to do that, then come +installed. See [[building_MIG|mig/gnu_mig/building]] about how to do that, then come back here. Additionally, building GNU Mach requires a C compiler, a standard C library and diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn index 5f09621d..eb1c0906 100644 --- a/microkernel/mach/mig.mdwn +++ b/microkernel/mach/mig.mdwn @@ -12,11 +12,11 @@ is included in the section entitled The Mach Interface Generator (MIG) is an [[IDL]] compiler. Based on an interface definition, it creates stubs to [[invoke]] object methods and to demultiplex incoming messages. These stubs conveniently hide -the details of Mach's [[IPC]] machinery. +the details of Mach's [[IPC]] machinery and make it easy to implement +and use Mach [[interface]]s as [[remote_procedure_calls_(RPC)|rpc]]. -GNU MIG is fully compatible with OSF MIG. - -* MIG's [homepage](http://www.gnu.org/software/hurd/mig.html) * [[Documentation]] -* [[Building]] - Building (and obtaining) MIG -* [[Open_Issues]] + +# Implementations + + * [[GNU_MIG]] diff --git a/microkernel/mach/mig/building.mdwn b/microkernel/mach/mig/building.mdwn deleted file mode 100644 index 2ec75e38..00000000 --- a/microkernel/mach/mig/building.mdwn +++ /dev/null @@ -1,72 +0,0 @@ -# Building the Mach Interface Generator from Source - -If you want to build the Mach Interface Generator yourself instead of just using a pre-built package, follow these instructions. - -## Getting the Source Code - -You can chose between getting the [sources from the developers's rcs](http://www.gnu.org/software/hurd/mig-download.html#cvs): - - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig - -... or (if you are working on a Debian system) the ones that are used for the [current Debian mig package](http://packages.debian.net/source/unstable/mig): - - $ apt-get source mig - -Please see the Debian [[running/debian/FAQ]] before using _apt-get source_. - -The unpacked source tree is around 1 MiB, and the build tree also is around 1 MiB. - -## Preparing for the Build - -### ... on Debian systems - -Building the Mach Interface Generator requires the _build-essential_ and _fakeroot_ packages, their dependencies and additional packages that are specified by the source mig package: - - # apt-get install build-essential fakeroot - # apt-get build-dep mig - -### ... on non-Debian systems - -Building the Mach Interface Generator requires a C compiler, a standard C library (with corresponding header files) and your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. - -Additionally, you need to have GNU Mach's header files installed. See -[[mach/gnu_mach/building]] about how to do that, then come back here. - -## Building and Installing - -### ... a _.deb_ file - -Change into the directory with the downloaded / unpacked MIG sources (_mig-1.3.1.99_): - - $ cd mig-1.3.1.99 - -Start the build process: - - $ dpkg-buildpackage -us -uc -b -rfakeroot - -You can then install / distribute the _.deb_ file which will drop out one directory above the current one. - -### [TODO] - -The Mach Interface Generator has to be built in a separate directory: - - $ mkdir mig-build - $ cd mig-build - -Find the root directory where you installed GNU Mach's header files and where you now intend to install the Mach Interface Generator (_~/gnu_) and the path to your Mach Interface Generator sources (\_[...]/mig) and configure it: - - $ GNU=~/gnu - $ TARGET_CPPFLAGS=-I"$GNU"/include [...]/mig/configure --prefix="$GNU" - -Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: - - $ make all install - -To make your _mig_ binary easily available, you should append something like the following to e.g. your _~/.bash\_profile_: - - PATH=~/gnu/bin:$PATH - export PATH - -If you already have e.g. _~/bin_ in your _$PATH_, you could also create a symbolic link: - - $ ln -s ~/gnu/bin/mig ~/bin/ diff --git a/microkernel/mach/mig/discussion.mdwn b/microkernel/mach/mig/discussion.mdwn deleted file mode 100644 index fdab3a45..00000000 --- a/microkernel/mach/mig/discussion.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -Created - --- [[Main/JoachimNilsson]] - 29 Oct 2002 - -The logo seems very programmer friendly as this web topic is intended. - --- [[Main/GrantBow]] - 15 Nov 2002 - -There's little traffic here and little content. Perhaps we should just remove this web? It seemed like a good idea to create it when we split the others off... - --- [[Main/GrantBow]] - 22 Dec 2002 - -Maybe, but not yet. Let's keep it for a while longer - say, three months. 1st April 2003. If the traffic still is low then we move the Mig topics to the Mach web ... - -...Mig = **Mach** Interface Generator. - --- [[Main/JoachimNilsson]] - 22 Dec 2002 diff --git a/microkernel/mach/mig/gnu_mig.mdwn b/microkernel/mach/mig/gnu_mig.mdwn new file mode 100644 index 00000000..4f5fb5c8 --- /dev/null +++ b/microkernel/mach/mig/gnu_mig.mdwn @@ -0,0 +1,24 @@ +[[meta copyright="Copyright © 2001, 2006, 2008 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]]."]]"""]] + +GNU MIG is the GNU distribution of the +[[Mach_3.0_interface_generator_*MIG*|mig]], as maintained by the GNU Hurd +developers for the GNU project. + +You need this tool to compile the GNU Mach and GNU Hurd distributions, and to +compile the GNU C library for the Hurd. Also, you will need it for other +software in the GNU system that uses Mach-based +[[inter-process_communication|ipc]]. + +GNU MIG is fully compatible with [[OSF_MIG|mig]]. + + * [[Building]] - building (and obtaining) GNU MIG + * [[Open_Issues]] diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn new file mode 100644 index 00000000..8b553b6b --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -0,0 +1,73 @@ +# Building the Mach Interface Generator from Source + +If you want to build the Mach Interface Generator yourself instead of just using a pre-built package, follow these instructions. + +## Getting the Source Code + +You can chose between getting the [sources from the developers' +RCS](http://savannah.gnu.org/cvs/?group=hurd): + + $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig + +... or (if you are working on a Debian system) the ones that are used for the [current Debian mig package](http://packages.debian.net/source/unstable/mig): + + $ apt-get source mig + +Please see the Debian [[hurd/running/debian/FAQ]] before using _apt-get source_. + +The unpacked source tree is around 1 MiB, and the build tree also is around 1 MiB. + +## Preparing for the Build + +### ... on Debian systems + +Building the Mach Interface Generator requires the _build-essential_ and _fakeroot_ packages, their dependencies and additional packages that are specified by the source mig package: + + # apt-get install build-essential fakeroot + # apt-get build-dep mig + +### ... on non-Debian systems + +Building the Mach Interface Generator requires a C compiler, a standard C library (with corresponding header files) and your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. + +Additionally, you need to have GNU Mach's header files installed. See +[[mach/gnu_mach/building]] about how to do that, then come back here. + +## Building and Installing + +### ... a _.deb_ file + +Change into the directory with the downloaded / unpacked MIG sources (_mig-1.3.1.99_): + + $ cd mig-1.3.1.99 + +Start the build process: + + $ dpkg-buildpackage -us -uc -b -rfakeroot + +You can then install / distribute the _.deb_ file which will drop out one directory above the current one. + +### [TODO] + +The Mach Interface Generator has to be built in a separate directory: + + $ mkdir mig-build + $ cd mig-build + +Find the root directory where you installed GNU Mach's header files and where you now intend to install the Mach Interface Generator (_~/gnu_) and the path to your Mach Interface Generator sources (\_[...]/mig) and configure it: + + $ GNU=~/gnu + $ TARGET_CPPFLAGS=-I"$GNU"/include [...]/mig/configure --prefix="$GNU" + +Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: + + $ make all install + +To make your _mig_ binary easily available, you should append something like the following to e.g. your _~/.bash\_profile_: + + PATH=~/gnu/bin:$PATH + export PATH + +If you already have e.g. _~/bin_ in your _$PATH_, you could also create a symbolic link: + + $ ln -s ~/gnu/bin/mig ~/bin/ diff --git a/microkernel/mach/mig/gnu_mig/open_issues.mdwn b/microkernel/mach/mig/gnu_mig/open_issues.mdwn new file mode 100644 index 00000000..7a6233da --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/open_issues.mdwn @@ -0,0 +1,20 @@ +[[meta copyright="Copyright © 2008 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="Open Issues"]] + +This is a dumping ground for open issues for GNU MIG. + +[[inline +pages="microkernel/mach/mig/gnu_mig/open_issues/* and !*/discussion" +show=0 +actions=yes +rootpage="microkernel/mach/mig/gnu_mig/open_issues" +postformtext="Add a new item titled:"]] diff --git a/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn b/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn new file mode 100644 index 00000000..93347759 --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn @@ -0,0 +1,14 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +E.g., both `/usr/include/hurd/process.h` and +`/usr/include/hurd/process_request.h` use `_process_user_` as an inclusion +guard. This leads to problems when both are needed, as is the case in +[[GDB]]'s `gdb/gnu-nat.c`. diff --git a/microkernel/mach/mig/open_issues.mdwn b/microkernel/mach/mig/open_issues.mdwn deleted file mode 100644 index 2d870695..00000000 --- a/microkernel/mach/mig/open_issues.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -[[meta copyright="Copyright © 2008 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="Open Issues"]] - -This is a dumping ground for open issues for GNU MIG. - -[[inline -pages="microkernel/mach/mig/open_issues/* and !*/discussion" -show=0 -actions=yes -rootpage="microkernel/mach/mig/open_issues" postformtext="Add a new item titled:"]] diff --git a/microkernel/mach/mig/open_issues/duplicate_inclusion_guards.mdwn b/microkernel/mach/mig/open_issues/duplicate_inclusion_guards.mdwn deleted file mode 100644 index 93347759..00000000 --- a/microkernel/mach/mig/open_issues/duplicate_inclusion_guards.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -[[meta copyright="Copyright © 2008 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]]."]]"""]] - -E.g., both `/usr/include/hurd/process.h` and -`/usr/include/hurd/process_request.h` use `_process_user_` as an inclusion -guard. This leads to problems when both are needed, as is the case in -[[GDB]]'s `gdb/gnu-nat.c`. diff --git a/mig-download.html b/mig-download.html deleted file mode 100644 index efbf1359..00000000 --- a/mig-download.html +++ /dev/null @@ -1,167 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Latest Release

-

-The latest release of MIG is version 1.3, 2002-03-08. However, it is -recommended that you use the version in CVS instead, as we are only a few steps -before we'll do another release from there. - - - -

CVS repository

-

-The MIG source code is managed in the version control system CVS. You can check out the CVS -repository through anonymous CVS over SSH with the following -instruction set. When prompted for a password for anoncvs, -simply press the Enter key. - -

-Source tree: - 
-cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig - -

Updates from within the module's directory do not need the -d parameter. - -

For the full details, read the savannah page. - -

Browsing the code

-

-You can also browse the CVS -repository of MIG with your web browser. The web pages are -generated dynamically at the time you request them and are always up -to date. -

-There is also a cross referenced -database of the Hurd, GNU Mach, MIG, and the GNU C library sources -online for you to browse. It provides better searching and browsing -facilities than the online CVS repository, but it is not always up to -date and does not contain history information. - -

-Some of these links are at other web sites not maintained by the -FSF. The FSF is not responsible for the content of these other web sites. -

- -
- -[ - - - English -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002, 2007 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/mig.html b/mig.html deleted file mode 100644 index 49e19a37..00000000 --- a/mig.html +++ /dev/null @@ -1,125 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - en -| es -| he -| pl -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

-

Table of Contents

- -

-

- -

Introduction to GNU MIG

-

-GNU MIG is the GNU distribution of the Mach 3.0 interface generator `MIG', as -maintained by the GNU Hurd developers for the GNU project. -

-The interface generator produces stub code from interface definition -(.defs) files. The stub code makes it easy to implement -and use Mach interfaces as remote procedure calls (RPC). -

-You need this tool to compile the GNU Mach and GNU Hurd distributions, and to -compile the GNU C library for the Hurd. Also, you will need it for other -software in the GNU system that uses Mach-based inter-process communication. - -

Status of the project

-

-MIG 1.3 was released in March 2002, and features compatibility with -OSF Mach. -

- -
- -[ - - - en -| es -| he -| pl -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2006 Free Software Foundation, Inc., -51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/sidebar.mdwn b/sidebar.mdwn index a368c6c3..6a132e6d 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -11,25 +11,27 @@ is included in the section entitled Welcome to... [[img hurd/logo/boxes-redrawn.png link=/hurd/logo]] ... the GNU Hurd! -* **[[Home|/index]]** -* **[[Community]]** -* **[[Documentation]]** -* **[[Hurd/Getting_Help]]** + * **[[Home|/index]]** + * **[[Community]]** + * **[[Documentation]]** + * **[[Hurd/Getting_Help]]** --- -* **[[Hurd]]**[[if test="destpage(hurd*)" then=" - * *[[Hurd/Documentation]]* - * *[[hurd/Running]]*"]] -* **[[microkernel/Mach]]**[[if test="destpage(microkernel/mach*)" then=" - * *[[microkernel/mach/GNU_Mach]]* - * *[[microkernel/mach/Documentation]]*"]] + * **[[Hurd]]**[[if test="destpage(hurd*)" then=" + * *[[Hurd/Documentation]]* + * *[[hurd/Running]]*"]] + * **[[microkernel/Mach]]**[[if test="destpage(microkernel/mach*)" then=" + * *[[microkernel/mach/Documentation]]* + * *[[microkernel/mach/GNU_Mach]]*"]] + * *[[microkernel/mach/MIG]]*[[if test="destpage(microkernel/mach/mig*)" then=" + * [[microkernel/mach/mig/GNU_MIG]]"]] --- -* **[[Debian_GNU/Hurd|hurd/running/debian]]** -* **[[GNU_system|hurd/running/gnu]]** + * **[[Debian_GNU/Hurd|hurd/running/debian]]** + * **[[GNU_system|hurd/running/gnu]]** --- -* **[[HurdNG|hurd/ng]]** + * **[[HurdNG|hurd/ng]]** -- cgit v1.2.3 From 155b3fde577d1f6e06ee1df2204ebcaea7c81935 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 09:44:21 +0100 Subject: Integrate two more HTML pages. --- download.html | 140 ----------------------------------------------------- hurd.mdwn | 19 +++++++- hurd/building.mdwn | 2 +- install.html | 126 ----------------------------------------------- 4 files changed, 18 insertions(+), 269 deletions(-) delete mode 100644 download.html delete mode 100644 install.html (limited to 'hurd') diff --git a/download.html b/download.html deleted file mode 100644 index d2d718f5..00000000 --- a/download.html +++ /dev/null @@ -1,140 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Esperanto -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

CVS repository

-

-The Hurd source code is managed in the version control system CVS. You can check out the CVS -repository through anonymous CVS over SSH with the following -instruction set. When prompted for a password for anoncvs, -simply press the Enter key. - -

-Source tree: - 
-cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd - -

Updates from within the module's directory do not need the -d parameter. - -

For the full details, read the savannah page. - -

Browsing the code

-

-You can also browse the CVS -repository of the Hurd with your web browser. The web pages are -generated dynamically at the time you request them and are always up -to date. -

-There is also a cross referenced -database of the Hurd, GNU Mach, MIG, and the GNU C library sources -online for you to browse. It provides better searching and browsing -facilities than the online CVS repository, but it is not always up to -date and does not contain history information. - -

-Some of these links are at other web sites not maintained by the -FSF. The FSF is not responsible for the content of these other web sites. -

- -
- -[ - - - English -| Esperanto -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/hurd.mdwn b/hurd.mdwn index 178817ca..61e83d21 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -1,5 +1,5 @@ -[[meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008 Free -Software Foundation, Inc."]] +[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 +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 @@ -9,6 +9,21 @@ 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]]."]]"""]] +The GNU Hurd is under active development. Because of that, there is no +*stable* version. We distribute the Hurd sources only through CVS at present. + +Although it is possible to bootstrap the GNU/Hurd system from the sources by +cross-compiling and installing the system software and the basic applications, +this is a difficult process. It is not recommended that you do this. Instead, +you should get a binary distribution of the GNU/Hurd, which comes with all the +GNU software precompiled and an installation routine which is easy to use. + +The Debian project has commited to provide such a binary distribution. +[[Debian_GNU/Hurd|running/debian]] is currently under development and available +in the *unstable* branch of the Debian archive. + +--- + [[toc ]] # Introduction diff --git a/hurd/building.mdwn b/hurd/building.mdwn index 7a24f70a..01586c84 100644 --- a/hurd/building.mdwn +++ b/hurd/building.mdwn @@ -16,7 +16,7 @@ within a Debian system. ## Getting the Source Code You can chose between getting the [sources from the developers's -RCS](http://www.gnu.org/software/hurd/download.html#cvs): +RCS](http://savannah.gnu.org/cvs/?group=hurd): $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd diff --git a/install.html b/install.html deleted file mode 100644 index b1517dae..00000000 --- a/install.html +++ /dev/null @@ -1,126 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Esperanto -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Latest version

-

-The GNU Hurd is under active development. Because of that, there is -no `stable' version. We distribute the Hurd sources only through CVS -at present. -

-Although it is possible to bootstrap the GNU/Hurd system from the sources -by cross-compiling and installing the system software and the basic -applications, this is a difficult process. It is not recommended that -you do this. Instead, you should get a binary distribution of the -GNU/Hurd, which comes with all the GNU software precompiled and an -installation routine which is easy to use. -

-The Debian project has commited to provide such a binary distribution. -Debian GNU/Hurd is -currently under development and available in the sid/unstable branch -of the Debian archive. Please see -the Debian GNU/Hurd -projects web page for installation instructions. - -

-Some of these links are at other web sites not maintained by the -FSF. The FSF is not responsible for the content of these other web sites. -

- -
- -[ - - - English -| Esperanto -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - -- cgit v1.2.3 From 24e7f01d6e6322e9d98412076dcf3f4d98196bb0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 11:37:33 +0100 Subject: Integrate auth.html, hurd-paper.html, hurd-talk.html. Move content from devel.html, docs.html. --- auth.html | 248 ----- contributing.mdwn | 10 +- devel.html | 159 ---- docs.html | 302 ------ documentation.mdwn | 16 +- hurd-paper.html | 812 ---------------- hurd-talk.html | 1151 ----------------------- hurd.mdwn | 2 - hurd/authentication.mdwn | 2 +- hurd/critique.mdwn | 4 +- hurd/documentation.mdwn | 48 +- hurd/documentation/auth.html | 168 ++++ hurd/documentation/hurd-paper.html | 760 +++++++++++++++ hurd/documentation/hurd-talk.html | 1061 +++++++++++++++++++++ hurd/hurd_hacking_guide.mdwn | 16 +- hurd/ng/position_paper.mdwn | 9 +- hurd/reference_manual.mdwn | 18 + hurd/running/distrib.mdwn | 2 +- hurd/running/gnu/universal_package_manager.mdwn | 2 +- hurd/translator.mdwn | 1 + hurd/translator/auth.mdwn | 13 + microkernel/faq/multiserver_microkernel.mdwn | 4 +- microkernel/mach/documentation.mdwn | 18 +- microkernel/mach/gnu_mach.mdwn | 1 + microkernel/mach/gnu_mach/reference_manual.mdwn | 26 + microkernel/mach/mig/documentation.mdwn | 3 +- 26 files changed, 2146 insertions(+), 2710 deletions(-) delete mode 100644 auth.html delete mode 100644 devel.html delete mode 100644 docs.html delete mode 100644 hurd-paper.html delete mode 100644 hurd-talk.html create mode 100644 hurd/documentation/auth.html create mode 100644 hurd/documentation/hurd-paper.html create mode 100644 hurd/documentation/hurd-talk.html create mode 100644 hurd/reference_manual.mdwn create mode 100644 hurd/translator/auth.mdwn create mode 100644 microkernel/mach/gnu_mach/reference_manual.mdwn (limited to 'hurd') diff --git a/auth.html b/auth.html deleted file mode 100644 index 676442ee..00000000 --- a/auth.html +++ /dev/null @@ -1,248 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - English -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
-

 -
-

Table of Contents

- -
- -

Introduction

-

-In this text, which mostly resembles the talk I gave at Libre Software -Meeting 2002 in Bordeaux, I will describe what the auth server does, -why it is so important and which cool things you can do with it, both -on the programming and the user side. I will also describe related -programs like the password and fakeauth servers. Note that this text -is targeted at programmers who want to understand the auth mechanism -in detail and are already familiar with concepts like Remote Procedure -Calls (RPCs) as well as the way User- and Group-IDs are used in the -POSIX world. - -

-The auth server is a very small server, therefore it gives a useful -example when you want to learn how a server typically looks like. One -reason why it is so small is that the auth interface, which it -implements, consists of only four RPCs. You can find the interface in -hurd/hurd/auth.defs and the server itself in hurd/auth/. - -

How IDs are represented and used

-

-Each process holds (usually) one port to auth (an auth_t in C source, -which actually is a mach_port_t, of course). The purpose of auth is -to manage User-IDs and Group-IDs, which is the reason why users often -will have no choice but to make use of the systems main auth server, -which does not listen on /servers/auth; instead you inherit a port to -auth from your parent process. Each such port is (internally in the -auth server) associated with a set of effective User- and Group-IDs as -well as a set of available User- and Group-IDs. So we have four sets -of IDs in total. The available IDs can be turned into corresponding -effective IDs at any time. - -

-When you send an auth_getids RPC on the port you hold, you will get -information about which IDs are associated with it, so you can figure -out which permissions you have. But how will a server know that you -have these permissions and therefore know which actions (e.g. writing -into file "foo") it is supposed to do on your behalf and which not? -The establishing of a trusted connection to a server works as follows: - -

    -
  1. A user wants a server to know its IDs
    2. -
  2. The user requests a reauthentication from the server
    3. -
  3. In this request the user will include a port
    4. -
  4. Both will hand this port to auth
    5. -
  5. The user uses auth_user_authenticate
    6. -
  6. The server uses auth_server_authenticate
    7. -
  7. The server also passes a new port to auth
    8. -
  8. auth matches these two requests
    9. -
  9. The user gets the new port from auth
    10. -
  10. The server learns about the IDs of the user
    11. -
  11. The user uses the new port for further communication
    12. -
- -

-We have different RPCs for users and servers because what we pass and -what we get back differs for them: Users get a port, and servers get -the sets of IDs, and have to specify the port which the user will get. - -

-It is interesting to note that auth can match the requests by -comparing two integers, because when you get the same port from two -people, you will have the same mach_port_t (which is nothing but an -integer). - -

-All of this of course only works if they use the same auth server, -which is why I said often you have no choice other than to use the -one main auth server. But this is no serious restriction, as the auth server has -almost no functionality one might want to replace. In fact, there is -one replacement for the default auth implementation, but more on that -later. - -

POSIX and beyond

-

-Before we examine what is possible with this design, let us take a -short look at how the POSIX semantics are implemented on top of this -design. When a program that comes out of POSIX-land asks for its own -effective User- or Group-ID, we will tell it about the first of the -effective IDs. In the same sense, the POSIX real User- or Group-ID is -the first available ID and the POSIX saved User- or Group-ID is the -second available ID, which is why you have the same ID two times in -the available IDs when you log into your GNU/Hurd machine (you can -figure out which IDs you have with the program "ids", that basically -just does an auth_getauth RPC). When you lack one of those IDs (for -example when you have no effective Group-ID), a POSIX program asking -for this particular information will get "-1" as the ID. - -

-But as you can imagine, we can do more than what POSIX specifies. Fox -example, we can modify our permissions. This is always done with the -auth_makeauth RPC. In this RPC, you specify the IDs that should be -associated with the new port. All of these IDs must be associated -with either the port where the RPC is sent to or one of the additional -ports you can specify; an exception is the superuser root, which is -allowed to creat ports that are associated with arbitrary IDs. -Hereby you can convert available into effective IDs. - -

-This opens the door to a bunch of nice features. For example, we have -the addauth program in the Hurd, which makes it possible to add an ID -to either a single process or a group of processes if you hold the ID or know the -appropriate password, and there is a corresponding rmauth program that -removes an ID. So when you are working on your computer with GNU -Emacs and want to edit a system configuration file, you switch to -Emacs' shell-mode, do an "addauth root", enter the password, edit the -file, and when you are done switch back to shell-mode and do "rmauth -root". These programs have some interesting options, and there are -various other programs, for setting the complete list of IDs (setauth) -and so on. - -

Related servers

-

-Finally, I want to explain two servers which are related to auth. The -first is the password server, which listens on /servers/password. If -you pass to it a User- or Group-ID and the correct password for it, it -will return a port to auth to you which is associated with the ID you -passed to it. It can create such a port because it is running as -root. So let us assume you are an FTP server process. You will start -as root, because you want to use port 21 (in this case, "port" does -not refer to a mach_port_t, of course). But then, you can drop all -your permissions so that you run without any ID. This makes it far -less dangerous to communicate with yet unknown users over the -network. But when someone now hands a username and password to you, -you can ask the password server for a new auth port. The password -server will check the data you pass to it, for example by looking into -/etc/shadow, and if it is valid, it will ask the auth server for a new -port. It receives this port from auth and then passes it on to you. -So you have raised your permissions. (And for the very curious: Yes, -we are well aware of the differences between this concept and -capabilities; and we also do have some kinds of capabilities in -various parts of the Hurd.) - -

-My second example is the fakeauth server. It also implements the auth -protocol. It is the part of the fakeroot implementation that gives a -process the impression that it runs as root, even if it doesn't. So -when the process asks fakeauth about its own IDs, fakeauth will tell -the process that it runs as root. But when the process wants to make -use of the authentication protocol described earlier in this text, -fakeauth will forward the request to its own auth server, which will -usually be the systems main auth server, which will then be able to -match the auth_*_authenticate requests. So what fakeauth does is -acting as a proxy auth server that gives someone the impression to run -as root, while not modifying what that one is allowed to do. - -

-At this point, I have said at least most of what can be said about the -auth server and the protocol it implements, so I will finish by saying -that it might be an interesting task (for you) to modify some existing -software to take advantage of the features I described here. - -

- -
- -[ - English -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2002 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/contributing.mdwn b/contributing.mdwn index 698d03b3..f1003389 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -52,7 +52,7 @@ is another possibility, see the page about [[running_a_Hurd_system|hurd/running]] for the full story. Then you can either play around and eventually strive to do something -useful or -- if you want -- ask us to assign something to you, depending +useful or -- if you want -- [[ask_us|contact_us]] to assign something to you, depending on the skills you have and the resources you intend to invest. Please spend some time with thinking about the items in this [[questionnaire]]. @@ -62,10 +62,10 @@ system, e.g., [[microkernels_for_beginners|microkernel/for_beginners]]. Until you can do the basic exercises listed there, you won't be able to significantly contribute to the Hurd. -For more reading resources, please see these web pages, and also -, - for links to a bunch of documents, -and in general. +For more reading resources, please see these web pages, for example, +[[Hurd_documentation|hurd/documentation]] and +[[Mach_documentation|microkernel/mach/documentation]] for links to a bunch of +documents. ### Porting Packages diff --git a/devel.html b/devel.html deleted file mode 100644 index 2a31f959..00000000 --- a/devel.html +++ /dev/null @@ -1,159 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - en -| eo -| es -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Contributing

-

-If you want to contribute to the Hurd, you should first install and -use it for a while, to become familiar with its features and design. -To join the development team, subscribe to the -Bug-Hurd -<bug-hurd@gnu.org> -mailing list, which is also the place where you can announce your -intentions, make your proposals and send in your patches. -(You can also send mail there without being subscribed to the list.) -

-There is also the -Hurd-devel-readers -mailing list. It is the read-only version of Hurd-devel, an internal -low-volume list restricted to the core developers of the Hurd. If you -want to follow up on the discussion of the Hurd experts, please reply -to the Bug-hurd mailing list. You can also follow the Hurd-devel -mailing list by browsing the web-based archive of -Hurd-devel. - -

Machinery: getting access to a -system

-

-There are essentially two possibilities: either you install the GNU/Hurd on a -system (see here) or if you don't -have a system to install it on, you can be provided with a shell account. See -this wiki page -for details. - -

Tasks

-

-Developing an operating system is a huge job, with a lot of different -things to do. To be able to keep track of issues, we use a -

-There is also an older (but still valid) list of specific items in the -task file -and in the -TODO file -of the Hurd source repository. - -
- -
- -[ - - - en -| eo -| es -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002, 2006, 2007 -Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/docs.html b/docs.html deleted file mode 100644 index 9c3a43f1..00000000 --- a/docs.html +++ /dev/null @@ -1,302 +0,0 @@ - - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Esperanto -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Introductory material, papers and other -informational documents

-

-

- -

Frequently asked questions

-

-Please check out the -Frequently -Asked Questions about the GNU Hurd (33k characters) and their -answers, which cover most issues a new user will be confronted with. -

-This document is available in several languages: -

- -

Wiki

-

A wiki is available for -collecting ideas and reciepes. Fell free -to contribute! - -

Some topics: - -

- - -

Reference manuals

- -
    - -
  • -

    -The GNU Mach Reference Manual documents the architecture, the usage and -the programming of the GNU Mach microkernel. At the moment, the manual -documents the interface completely, but is not very useful as a tutorial or -introduction into the Mach architecture. -

    -Available Formats: -

    -

    -If you want to work on the manual, you're advised to make a checkout of the source tree. Be sure to get the -GNU Mach 1 branch when you intend to work on the manual. You -can then find the manual's sources in the doc/ directory. Please -submit any modifications to <bug-hurd@gnu.org> (if possible in -unidiff format, as produced by diff -u). - -

    • - -
  • -

    -The GNU Hurd Reference Manual documents the architecture, the usage -and the programming of the GNU Hurd. At the moment, the manual is -quite incomplete. -

    -Available Formats: -

    -

    -If you want to work on the manual, you're advised to make a checkout of the source tree. You can then find the manual's -sources in the doc/ directory. Please submit any modifications to -<bug-hurd@gnu.org> (if possible in -unidiff format, as produced by diff -u). - -

    • - -
- -
- -
- -[ - - - English -| Esperanto -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007 -Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/documentation.mdwn b/documentation.mdwn index 45bb5ffc..4e4b4b23 100644 --- a/documentation.mdwn +++ b/documentation.mdwn @@ -8,21 +8,13 @@ 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]]."]]"""]] -# General +Documentation for... - * [GNU Hurd Documentation](http://www.gnu.org/software/hurd/docs.html) + * [[GNU_Hurd|hurd/documentation]] + * [[Mach|microkernel/mach/documentation]] -# Introductory Material - -## External - - * [*Examining the Legendary HURD - Kernel*](http://www.informit.com/articles/printerfriendly.aspx?p=1180992), - an article by David Chisnall. - - Also covers a bit of GNU's and the Hurd's history, fundamental techniques - applied, comparisions to other systems. + * [[MIG|microkernel/mach/mig/documentation]] # [[Unix]] Programming diff --git a/hurd-paper.html b/hurd-paper.html deleted file mode 100644 index bb49829c..00000000 --- a/hurd-paper.html +++ /dev/null @@ -1,812 +0,0 @@ - - - -Towards a New Strategy of OS Design - - - -

Towards a New Strategy of OS Design

- [image of a Hurd Metafont Logo] (jpeg 10k) -(jpeg 20k) -no gifs due to patent problems -
-
-[ - - - English -| Hebrew -| Turkish -] - -

-This article explains why FSF is developing a new operating system named the -Hurd, which will be a foundation of the whole GNU system. -The Hurd is built -on top of CMU's Mach 3.0 kernel and uses Mach's virtual memory management and -message-passing facilities. -The GNU C Library will provide the Unix system -call interface, and will call the Hurd for needed services it can't provide -itself. -The design and implementation of the Hurd is being lead by Michael -Bushnell, with assistance from Richard Stallman, Roland McGrath, -Jan Brittenson, and others. - -

Part 1: A More Usable Approach to OS Design

-

-The fundamental purpose of an operating system (OS) is to enable a variety of -programs to share a single computer efficiently and productively. -This -demands memory protection, preemptively scheduled timesharing, coordinated -access to I/O peripherals, and other services. -In addition, an OS can allow -several users to share a computer. -In this case, efficiency demands services -that protect users from harming each other, enable them to share without -prior arrangement, and mediate access to physical devices. -

-On today's computer systems, programmers usually implement these goals -through a large program called the kernel. -Since this program must be -accessible to all user programs, it is the natural place to add functionality -to the system. -Since the only model for process interaction is that of -specific, individual services provided by the kernel, no one creates other -places to add functionality. -As time goes by, more and more is added to the -kernel. -

-A traditional system allows users to add components to a kernel only if they -both understand most of it and have a privileged status within the system. -Testing new components requires a much more painful edit-compile-debug cycle -than testing other programs. -It cannot be done while others are using the -system. -Bugs usually cause fatal system crashes, further disrupting others' -use of the system. -The entire kernel is usually non-pageable. -(There are -systems with pageable kernels, but deciding what can be paged is difficult -and error prone. -Usually the mechanisms are complex, making them difficult -to use even when adding simple extensions.) -

-Because of these restrictions, functionality which properly belongs -behind -the wall of a traditional kernel is usually left out of systems unless it is -absolutely mandatory. -Many good ideas, best done with an open/read/write -interface cannot be implemented because of the problems inherent in the -monolithic nature of a traditional system. -Further, even among those with -the endurance to implement new ideas, only those who are privileged users of -their computers can do so. -The software copyright system darkens the mire by -preventing unlicensed people from even reading the kernel source. -

-Some systems have tried to address these difficulties. -Smalltalk-80 and -the Lisp Machine both represented one method of getting around the problem. -System code is not distinguished from user code; all of the system is -accessible to the user and can be changed as need be. -Both systems were -built around languages that facilitated such easy replacement and extension, -and were moderately successful. -But they both were fairly poor at insulating -users and programs from each other, failing one of the principal goals of OS -design. -

-Most projects that use the Mach 3.0 kernel carry on the hard-to-change -tradition of OS design. -The internal structure is different, but the same -heavy barrier between user and system remains. -The single-servers, while -fairly easy to construct, inherit all the deficiencies of the monolithic -kernels. -

-A multi-server divides the kernel functionality up into logical blocks with -well-defined interfaces. -Properly done, it is easier to make changes and add -functionality. -So most multi-server projects do somewhat better. -Much more -of the system is pageable. -You can debug the system more easily. -You can -test new system components without interfering with other users. -But the -wall between user and system remains; no user can cross it without special -privilege. -

-The GNU Hurd, by contrast, is designed to make the area of -system -code as -limited as possible. -Programs are required to communicate only with a few -essential parts of the kernel; the rest of the system is replaceable -dynamically. -Users can use whatever parts of the remainder of the system -they want, and can easily add components themselves for other users to take -advantage of. -No mutual trust need exist in advance for users to use each -other's services, nor does the system become vulnerable by trusting the -services of arbitrary users. -

-This has been done by identifying those system components which users -must -use in order to communicate with each other. -One of these is responsible for -identifying users' identities and is called the - -authentication server. - -In -order to establish each other's identities, programs must communicate, each -with an authentication server they trust. -Another component establishes -control over system components by the superuser, provides global bookkeeping -operations, and is called the - -process server. - -

-Not all user programs need to communicate with the process server; it is only -necessary for programs which require its services. -Likewise, the -authentication server is only necessary for programs that wish to communicate -their identity to another. -None of the remaining services carry any special -status; not the network implementation, the filesystems, the program -execution mechanism (including setuid), or any others. - -

The Translator Mechanism

-

-The Hurd uses Mach ports primarily as methods for communicating between users -and servers. -(A Mach port is a communication point on a Mach task where -messages are sent and received.) Each port implements a particular set of -protocols, representing operations that can be undertaken on the underlying -object represented by the port. -Some of the protocols specified by the Hurd -are the I/O protocol, used for generic I/O operations; the file protocol, -used for filesystem operations; the socket protocol, used for network -operations; and the process protocol, used for manipulating processes et al. -

-Most servers are accessed by opening files. -Normally, when you open a file, -you create a port associated with that file that is owned by the server -that owns the directory containing the file. -For example, a disk-based -filesystem will normally serve a large number of ports, each of which -represents an open file or directory. -When a file is opened, the server -creates a new port, associates it with the file, and returns the port to the -calling program. -

-However, a file can have a -translator -associated with it. -In this case, -rather than return its own port which refers to the contents of the file, the -server executes a translator program associated with that file. -This -translator is given a port to the actual contents of the file, and is then -asked to return a port to the original user to complete the open operation. -

-This mechanism is used for -mount -by having a translator associated with -each mount point. -When a program opens the mount point, the translator (in -this case, a program which understands the disk format of the mounted -filesystem) is executed and returns a port to the program. -After the -translator is started, it need not be run again unless it dies; the parent -filesystem retains a port to the translator to use in further requests. -

-The owner of a file can associate a translator with it without special -permission. -This means that any program can be specified as a translator. -Obviously the system will not work properly if the translator does not -implement the file protocol correctly. -However, the Hurd is constructed so -that the worst possible consequence is an interruptible hang. -

-One way to use translators is to access hierarchically structured data using -the file protocol. -For example, all the complexity of the user interface to -the -ftp -program is removed. -Users need only know that a particular -directory represents FTP and can use all the standard file manipulation -commands (e.g -ls -or -cp) -to access the remote system, rather than learning -a new set. -Similarly, a simple translator could ease the complexity of -tar -or -gzip. -(Such transparent access would have some added cost, but it would -be convenient.) - -

Generic Services

-

-With translators, the filesystem can act as a rendezvous for interfaces which -are not similar to files. -Consider a service which implements some version -of the X protocol, using Mach messages as an underlying transport. -For each -X display, a file can be created with the appropriate program as its -translator. -X clients would open that file. -At that point, few file -operations would be useful (read and write, for example, would be useless), -but new operations ( -XCreateWindow -or -XDrawText) -might become meaningful. -In this case, the filesystem protocol is used only to manipulate -characteristics of the node used for the rendezvous. -The node need not -support I/O operations, though it should reply to any such messages with a -message_not_understood -return code. -

-This translator technique is used to contact most of the services in the Hurd -that are not structured like hierarchical filesystems. -For example, the -password server, which hands out authorization tags in exchange for -passwords, is contacted this way. -Network protocol servers are also -contacted in this fashion. -Roland McGrath thought up this use of translators. - -

Clever Filesystem Pictures

-

-In the Hurd, translators can also be used to present a filesystem-like view -of another part of the filesystem, with some semantics changed. -For example, -it would be nice to have a filesystem that cannot itself be changed, but -nonetheless records changed versions of its files elsewhere. -(This could be -useful for source code management.) -

-The Hurd will have a translator which creates a directory which is a -conceptual union of other directories, with collision resolution rules of -various sorts. -This can be used to present a single directory to users that -contains all the programs they would want to execute. -There are other useful -variations on this theme. - -

What The User Can Do

-

-No translator gains extra privilege by virtue of being hooked into the -filesystem. -Translators run with the uid of the owner of the file being -translated, and can only be set or changed by that owner. -The I/O and -filesystem protocols are carefully designed to allow their use by mutually -untrusting clients and servers. -Indeed, translators are just ordinary -programs. -The GNU C library has a variety of facilities to make common sorts -of translators easier to write. -

-Some translators may need special privileges, such as the password server or -translators which allow setuid execution. -These translators could be run by -anyone, but only if they are set on a root-owned node would they be able to -provide all their services successfully. -This is analogous to letting any -user call the -reboot -system call, but only honoring it if that user is root. - -

Why This Is So Different

-

-What this design provides is completely novel to the Unix world. -Until now, -OSs have kept huge portions of their functionality in the realm of system -code, thus preventing its modification and extension except in extreme need. -Users cannot replace parts of the system in their programs no matter how much -easier that would make their task, and system managers are loath to install -random tweaks off the net into their kernels. -

-In the Hurd, users can change almost all of the things that are decided for -them in advance by traditional systems. -In combination with the tremendous -control given by the Mach kernel over task address spaces and properties, the -Hurd provides a system in which users will, for the first time, be able to -replace parts of the system they dislike, without disrupting other users. -

-Most Mach-based OSs to date have mostly implemented a wider set of the - -same old - -Unix semantics in a new environment. -In contrast, GNU is extending -those semantics to allow users to improve, bypass, or replace them. - - -

Part 2: A Look at Some of the Hurd's Beasts

-

The Authentication Server

-

-One of the Hurd's more central servers is the authentication server. -Each -port to this server identifies a user and is associated by this server with -an -id block. -Each id block contains sets of user and group ids. -Either -set may be empty. -This server is not the same as the password server -referred to above. -

-The authentication server exports three services. -First, it provides simple -boolean operations on authentication ports: given two authentication ports, -this server will provide a third port representing the union of the two sets -of uids and gids. -Second, this server allows any user with a uid of zero to -create an arbitrary authentication port. -Finally, this server provides RPCs -(Remote Procedure Calls between different programs and possibly different -hosts) which allow mutually untrusting clients and servers to establish their -identities and pass initial information on each other. -This is crucial to -the security of the filesystem and I/O protocols. -

-Any user could write a program which implements the authentication protocol; -this does not violate the system's security. -When a service needs to -authenticate a user, it communicates with its trusted authentication server. -If that user is using a different authentication server, the transaction will -fail and the server can refuse to communicate further. -Because, in effect, -this forces all programs on the system to use the same authentication server, -we have designed its interface to make any safe operation possible, and to -include no extraneous operations. -(This is why there is a separate password -server.) -

The Process Server

-

-The process server acts as an information categorization repository. -There -are four main services supported by this server. -First, the process server -keeps track of generic host-level information not handled by the Mach kernel. -For example, the hostname, the hostid, and the system version are maintained -by the process server. -Second, this server maintains the Posix notions of -sessions and process groups, to help out programs that wish to use Posix -features. -

-Third, the process server maintains a one-to-one mapping between Mach tasks -and Hurd processes. -Every task is assigned a pid. -Processes can register a -message port with this server, which can then be given out to any program -which requests it. -This server makes no attempt to keep these message ports -private, so user programs are expected to implement whatever security they -need themselves. -(The GNU C Library provides convenient functions for all -this.) Processes can tell the process server their current `argv' and `envp' -values; this server will then provide, on request, these vectors of arguments -and environment. -This is useful for writing -ps-like -programs and also -makes it easier to hide or change this information. -None of these features -are mandatory. -Programs are free to disregard all of this and never register -themselves with the process server at all. -They will, however, still have a -pid assigned. -

-Finally, the process server implements -process collections, -which are used -to collect a number of process message ports at the same time. -Also, -facilities are provided for converting between pids, process server ports, -and Mach task ports, while ensuring the security of the ports managed. -

-It is important to stress that the process server is optional. -Because of -restrictions in Mach, programs must run as root in order to identify all the -tasks in the system. -But given that, multiple process servers could -co-exist, each with their own clients, giving their own model of the -universe. -Those process server features which do not require root privileges -to be implemented could be done as per-user servers. -The user's hands are -not tied. -

Transparent FTP

-

-Transparent FTP is an intriguing idea whose time has come. -The popular -ange-ftp -package available for GNU Emacs makes access to FTP files -virtually transparent to all the Emacs file manipulation functions. -Transparent FTP does the same thing, but in a system wide fashion. -This -server is not yet written; the details remain to be fleshed out, and will -doubtless change with experience. -

-In a BSD kernel, a transparent FTP filesystem would be no harder to write -than in the Hurd. -But mention the idea to a BSD kernel hacker, and the -response is that ``such a thing doesn't belong in the kernel''. -In a sense, -this is correct. -It violates all the layering principles of such systems to -place such things in the kernel. -The unfortunate side effect, however, is -that the design methodology (which is based on preventing users from changing -things they don't like) is being used to prevent system designers from making -things better. -(Recent BSD kernels make it possible to write a user program -that provides transparent FTP. -An example is -alex, -but it needs to run -with full root privileges.) -

-In the Hurd, there are no obstacles to doing transparent FTP. -A translator -will be provided for the node -/ftp. -The contents of -/ftp -will probably -not be directly listable, though further subdirectories will be. -There will -be a variety of possible formats. -For example, to access files on uunet, one -could - -cd /ftp/ftp.uu.net:anonymous:mib@gnu. - -Or to access files on a remote -account, one might - -cd /ftp/gnu.org:mib:passwd. - -Parts of this -command could be left out and the transparent FTP program would read them -from a user's -.netrc -file. -In the last case, one might just - -cd /ftp/gnu.org; - -when the rest of the data is already in -.netrc. -

-There is no need to do a -cd -first--use any file command. -To find out about -RFC 1097 (the Telnet Subliminal Message Option), just type - -more /ftp/ftp.uu.net/inet/rfc/rfc1097. - -A copy command to a local disk -could be used if the RFC would be read frequently. -

Filesystems

-

-Ordinary filesystems are also being implemented. -The initial release of the -Hurd will contain a filesystem upwardly compatible with the BSD 4.4 Fast File -System. -In addition to the ordinary semantics, it will provide means to -record translators, offer thirty-two bit user ids and group ids, and supply a -new id per file, called the -author -of the file, which can be set by the -owner arbitrarily. -In addition, because users in the Hurd can have multiple -uids (or even none), there is an additional set of permission bits providing -access control for - -unknown user - -(no uids) as distinct from - -known but arbitrary user - -(some uids: the existing -world -category of file -permissions). -

-The Network File System protocol will be implemented using 4.4 BSD as a -starting point. -A log-structured filesystem will also be implemented using -the same ideas as in Sprite, but probably not the same format. -A GNU network -file protocol may be designed in time, or NFS may be extended to remove its -deficiencies. -There will also be various ``little'' filesystems, such as the -MS-DOS filesystem, to help people move files between GNU and other OSs. - -

Terminals

-

-An I/O server will provide the terminal semantics of Posix. -The GNU C -Library has features for keeping track of the controlling terminal and for -arranging to have proper job control signals sent at the proper times, as -well as features for obeying keyboard and hangup signals. -

-Programs will be able to insert a terminal driver into communications -channels in a variety of ways. -Servers like -rlogind -will be able to insert -the terminal protocol onto their network communication port. -Pseudo-terminals will not be necessary, though they will be provided for -backward compatibility with older programs. -No programs in GNU will depend -on them. -

-Nothing about a terminal driver is forced upon users. -A terminal driver -allows a user to get at the underlying communications channel easily, to -bypass itself on an as-needed basis or altogether, or to substitute a -different terminal driver-like program. -In the last case, provided the -alternate program implements the necessary interfaces, it will be used by the -C Library exactly as if it were the ordinary terminal driver. -

-Because of this flexibility, the original terminal driver will not provide -complex line editing features, restricting itself to the behavior found in -Posix and BSD. -In time, there will be a -readline-based -terminal driver, -which will provide complex line-editing features for those users who want -them. -

-The terminal driver will probably not provide good support for the -high-volume, rapid data transmission required by UUCP or SLIP. -Those -programs do not need any of its features. -Instead they will be using the -underlying Mach device ports for terminals, which support moving large -amounts of data efficiently. - -

Executing Programs

-

-The implementation of the -execve -call is spread across three programs. -The -library marshals the argument and environment vectors. -It then sends a -message to the file server that holds the file to be executed. -The file -server checks execute permissions and makes whatever changes it desires in -the exec call. -For example, if the file is marked setuid and the fileserver -has the ability, it will change the user identification of the new image. -The file server also decides if programs which had access to the old task -should continue to have access to the new task. -If the file server is -augmenting permissions, or executing an unreadable image, then the exec needs -to take place in a new Mach task to maintain security. -

-After deciding the policy associated with the new image, the filesystem calls -the exec server to load the task. -This server, using the BFD (Binary File -Descriptor) library, loads the image. -BFD supports a large number of object -file formats; almost any supported format will be executable. -This server -also handles scripts starting with -#!, -running them through the indicated -program. -

-The standard exec server also looks at the environment of the new image; if -it contains a variable -EXECSERVERS -then it uses the programs specified -there as exec servers instead of the system default. -(This is, of course, -not done for execs that the file server has requested be kept secure.) -

-The new image starts running in the GNU C Library, which sends a message to -the exec server to get the arguments, environment, umask, current directory, -etc. -None of this additional state is special to the file or exec servers; -if programs wish, they can use it in a different manner than the Library. - -

New Processes

-

-The -fork -call is implemented almost entirely in the GNU C Library. -The new -task is created by Mach kernel calls. -The C Library arranges to have its -image inherited properly. -The new task is registered with the process server -(though this is not mandatory). -The C Library provides vectors of functions -to be called at fork time: one vector to be called before the fork, one after -in the parent, and one after in the child. -(These features should not be -used to replace the normal fork-calling sequence; it is intended for -libraries which need to close ports or clean up before a fork occurs.) -The C -library will implement both fork calls specified by the draft Posix.4a (the -proposed standard dealing with the threads extension to the real-time -extension). -

-Nothing forces the user to create new tasks this way. -If a program wants to -use almost the normal fork, but with some special characteristics, then it -can do so. -Hooks will be provided by the C Library, or the function can even -be completely replaced. -None of this is possible in a traditional Unix -system. - -

Asynchronous Messages

-

-As mentioned above, the process server maintains a - -message port - -for each -task registered with it. -These ports are public, and are used to send -asynchronous messages to the task. -Signals, for example, are sent to the -message port. -The signal message also provides a port as an indication that -the sender should be trusted to send the signal. -The GNU C Library lists a -variety of ports in a table, each of which identifies a set of signals that -can be sent by anyone who possesses that port. -For example, if the user -possesses the task's kernel port, it is allowed to send any signal. -If the -user possesses a special - -terminal id - -port, it is allowed to send the -keyboard and hangup signals. -Users can add arbitrary new entries into the C -library's signal permissions table. -

-When a process's process group changes, the process server will send it a -message indicating the new process group. -In this case, the process server -proves its authority by providing the task's kernel port. -

-The C library also has messages to add and delete uids currently used by the -process. -If new uids are sent to the program, the library adds them to its -current set, and then exchanges messages with all the I/O servers it knows -about, proving to them its new authorization. -Similarly, a message can -delete uids. -In the latter case, the caller must provide the process's task -port. -(You can't harm a process by giving it extra permission, but you can -harm it by taking permission away.) The Hurd will provide user programs to -send these messages to processes. -For example, the -su -command will be able -to cause all the programs in your current login session, to gain a new uid, -rather than spawn a subshell. -

-The C library will allow programs to add asynchronous messages they wish to -recognize, as well as prevent recognition of the standard set. -

Making It Look Like Unix

-

-The C Library will implement all of the calls from BSD and Posix as well as -some obvious extensions to them. -This enables users to replace those calls -they dislike or bypass them entirely, whereas in Unix the calls must be used -``as they come'' with no alternatives possible. -

-In some environments binary compatibility will also be supported. -This works -by building a special version of the library which is then loaded somewhere -in the address space of the process. -(For example, on a VAX, it would be -tucked in above the stack.) A feature of Mach, called system call -redirection, is then used to trap Unix system calls and turn them into jumps -into this special version of the library. -(On almost all machines, the cost -of such a redirection is very small; this is a highly optimized path in Mach. -On a 386 it's about two dozen instructions. -This is little worse than a -simple procedure call.) -

-Many features of Unix, such as signal masks and vectors, are handled -completely by the library. -This makes such features significantly cheaper -than in Unix. -It is now reasonable to use -sigblock -extensively to protect -critical sections, rather than seeking out some other, less expensive method. - -

Network Protocols

-

-The Hurd will have a library that will make it very easy to port 4.4 BSD -protocol stacks into the Hurd. -This will enable operation, virtually for -free, of all the protocols supported by BSD. -Currently, this includes the -CCITT protocols, the TCP/IP protocols, the Xerox NS protocols, and the ISO -protocols. -

-For optimal performance some work would be necessary to take advantage of -Hurd features that provide for very high speed I/O. -For most protocols this -will require some thought, but not too much time. -The Hurd will run the -TCP/IP protocols as efficiently as possible. -

-As an interesting example of the flexibility of the Hurd design, consider the -case of IP trailers, used extensively in BSD for performance. -While the Hurd -will be willing to send and receive trailers, it will gain fairly little -advantage in doing so because there is no requirement that data be copied and -avoiding copies for page-aligned data is irrelevant. - -

- -[ - - - English -| Hebrew -| Turkish -] - -
- -Return to GNU's home page. -

-FSF & GNU inquiries & questions to -gnu@gnu.org. -Other ways to contact the FSF. -

-Comments on these web pages to -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 1996 Trent Fisher -
-Copyright (C) 1996, 1997, 1998, 2007 Free Software Foundation, Inc., -51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved.

-Updated: - -19 Dec 1998 jonas - -

- - diff --git a/hurd-talk.html b/hurd-talk.html deleted file mode 100644 index 630bbc7d..00000000 --- a/hurd-talk.html +++ /dev/null @@ -1,1151 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
-

Talk about the Hurd

-

-This talk about the Hurd was written by Marcus Brinkmann for -

    -
  • OSDEM, Brussels, 4. Feb 2001, -
  • Frühjahrsfachgespräche, Cologne, 2. Mar 2001 and -
  • Libre Software Meeting, Bordeaux, 4. Jul 2001. -
- -

Introduction

-

-When we talk about free software, we usually refer to the free -software licenses. We also need relief from software patents, so our -freedom is not restricted by them. But there is a third type of -freedom we need, and that's user freedom. - -

-Expert users don't take a system as it is. They like to change the -configuration, and they want to run the software that works best for -them. That includes window managers as well as your favourite text -editor. But even on a GNU/Linux system consisting only of free -software, you can not easily use the filesystem format, network -protocol or binary format you want without special privileges. In -traditional unix systems, user freedom is severly restricted by the -system administrator. - -

-The Hurd removes these restrictions from the user. It provides an -user extensible system framework without giving up POSIX compatibility -and the unix security model. Throughout this talk, we will see that -this brings further advantages beside freedom. - -

Overview

-
- -

-The Hurd is a POSIX compatible multi-server -system operating on top of the GNU Mach microkernel. - -

-Topics: -

    -
  • GNU Mach
    • -
  • The Hurd
    • -
  • Development
    • -
  • Debian GNU/Hurd
    • -
-
- -

-The Hurd is a POSIX compatible multi-server system operating on top of -the GNU Mach Microkernel. - -

-I will have to explain what GNU Mach is, so we start with that. Then -I will talk about the Hurd's architecture. After that, I will give a -short overview on the Hurd libraries. Finally, I will tell you how -the Debian project is related to the Hurd. - -

Historicals

- -
-
    -
  • 1983: Richard Stallman founds the GNU project.
    • -
  • 1988: Decision is made to use Mach 3.0 as the kernel.
    • -
  • 1991: Mach 3.0 is released under compatible license.
    • -
  • 1991: Thomas Bushnell, BSG, founds the Hurd project.
    • -
  • 1994: The Hurd boots the first time.
    • -
  • 1997: Version 0.2 of the Hurd is released.

    • -
  • 1998: Debian hurd-i386 archive is created.
    • -
  • 2001: Debian GNU/Hurd snapshot fills three CD images.
    • -
-
- -

-When Richard Stallman founded the GNU project in 1983, he wanted to -write an operating system consisting only of free software. Very -soon, a lot of the essential tools were implemented, and released -under the GPL. However, one critical piece was missing: The kernel. -

-After considering several alternatives, it was decided not to write a -new kernel from scratch, but to start with the Mach microkernel. This -was in 1988, and it was not before 1991 that Mach was released under a -license allowing the GNU project to distribute it as a part of the -system. -

-In 1998, I started the Debian GNU/Hurd project, and in 2001 the number -of available GNU/Hurd packages fills three CD images. - -

Kernel Architectures

-
-

-Microkernel: -

    -
  • Enforces resource management (paging, scheduling)
    • -
  • Manages tasks
    • -
  • Implements message passing for IPC
    • -
  • Provides basic hardware support
    • -
-

-Monolithic kernel: -

    -
  • No message passing necessary
    • -
  • Rich set of features (filesystems, authentication, network - sockets, POSIX interface, ...)
    • -
-
-

-Microkernels were very popular in the scientific world around that -time. They don't implement a full operating system, but only the -infrastructure needed to enable other tasks to implement most -features. In contrast, monolithical kernels like Linux contain -program code of device drivers, network protocols, process management, -authentication, file systems, POSIX compatible interfaces and much -more. -

-So what are the basic facilities a microkernel provides? In general, -this is resource management and message passing. Resource management, -because the kernel task needs to run in a special privileged mode of -the processor, to be able to manipulate the memory management unit and -perform context switches (also to manage interrupts). Message -passing, because without a basic communication facility the other -tasks could not interact to provide the system services. Some -rudimentary hardware device support is often necessary to bootstrap -the system. So the basic jobs of a microkernel are enforcing the -paging policy (the actual paging can be done by an external pager -task), scheduling, message passing and probably basic hardware device -support. -

-Mach was the obvious choice back then, as it provides a rich set of -interfaces to get the job done. Beside a rather brain-dead device -interface, it provides tasks and threads, a messaging system allowing -synchronous and asynchronous operation and a complex interface for -external pagers. It's certainly not one of the sexiest microkernels -that exist today, but more like a big old mama. The GNU project -maintains its own version of Mach, called GNU Mach, which is based on -Mach 4.0. In addition to the features contained in Mach 4.0, the GNU -version contains many of the Linux 2.0 block device and network card -drivers. -

-A complete treatment of the differences between a microkernel and -monolithical kernel design can not be provided here. But a couple of -advantages of a microkernel design are fairly obvious. - -

Micro vs Monolithic

-
-

-Microkernel -

    -
  • Clear cut responsibilities -
  • Flexibility in operating system design, easier debugging
    • -
  • More stability (less code to break)
    • -
  • New features are not added to the kernel
    • -
-

-Monolithic kernel -

    -
  • Intolerance or creeping featuritis
    • -
  • Danger of spaghetti code
    • -
  • Small changes can have far reaching side effects
    • -
-
-

-Because the system is split up into several components, clean -interfaces have to be developed, and the responsibilities of each part -of the system must be clear. -

-Once a microkernel is written, it can be used as the base for several -different operating systems. Those can even run in parallel which -makes debugging easier. When porting, most of the hardware dependant -code is in the kernel. -

-Much of the code that doesn't need to run in the special kernel mode -of the processor is not part of the kernel, so stability increases -because there is simply less code to break. -

-New features are not added to the kernel, so there is no need to hold -the barrier high for new operating system features. -

-Compare this to a monolithical kernel, where you either suffer from -creeping featuritis or you are intolerant of new features (we see both -in the Linux kernel). -

-Because in a monolithical kernel, all parts of the kernel can access -all data structures in other parts, it is more likely that short cuts -are used to avoid the overhead of a clean interface. This leads to a -simple speed up of the kernel, but also makes it less comprehensible -and more error prone. A small change in one part of the kernel can -break remote other parts. - -

Single Server vs Multi Server

-
-

-Single Server -

    -
  • A single task implements the functionality of the operating system.
    • -
-

-Multi Server -

    -
  • Many tasks cooperate to provide the system's functionality.
    • -
  • One server provides only a small but well-defined part of the - whole system.
    • -
  • The responsibilities are distributed logically among the servers.
    • -
-

-A single-server system is comparable to a monolithic kernel system. It -has similar -advantages and disadvantages. -

-

-There exist a couple of operating systems based on Mach, but they all -have the same disadvantages as a monolithical kernel, because those -operating systems are implemented in one single process running on top -of the kernel. This process provides all the services a monolithical -kernel would provide. This doesn't make a whole lot of sense (the -only advantage is that you can probably run several of such isolated -single servers on the same machine). Those systems are also called -single-server systems. The Hurd is the only usable multi-server -system on top of Mach. In the Hurd, there are many server programs, -each one responsible for a unique service provided by the operating -system. These servers run as Mach tasks, and communicate using the -Mach message passing facilities. One of them does only provide a -small part of the functionality of the system, but together they build -up a complete and functional POSIX compatible operating system. - -

Multi Server is superior, ...

-
-

-Any multi-server has advantages over single-server: -

    -
  • Clear cut responsibilities
    • -
  • More stability: If one server dies, all others remain
    • -
  • Easier development cycle: Testing without reboot (or replacing - running servers), debugging with gdb
    • -
  • Easier to make changes and add new features -
-
-

-Using several servers has many advantages, if done right. If a file -system server for a mounted partition crashes, it doesn't take down -the whole system. Instead the partition is "unmounted", and -you can try to start the server again, probably debugging it this time -with gdb. The system is less prone to errors in individual -components, and over-all stability increases. The functionality of -the system can be extended by writing and starting new servers -dynamically. (Developing these new servers is easier for the reasons -just mentioned.) -

-But even in a multi-server system the barrier between the system and -the users remains, and special privileges are needed to cross it. We -have not achieved user freedom yet. - -

The Hurd even more so.

-
-

-The Hurd goes beyond all this, and allows users to write and run their -servers, too! -

    -
  • Users can replace system servers dynamically with their own - implementations.
    • -
  • Users can decide what parts of the remainder of the system they - want to use.
    • -
  • Users can extend the functionality of the system.
    • -
  • No mutual trust necessary to make use of other users - services.
    • -
  • Security of the system is not harmed by trusting users - services.
    • -
-
-

-To quote Thomas Bushnell, BSG, from his paper -``A new strategy towards OS -design'' (1996): -

-The GNU Hurd, by contrast, is designed to make the area of system code -as limited as possible. Programs are required to communicate only -with a few essential parts of the kernel; the rest of the system is -replaceable dynamically. Users can use whatever parts of the -remainder of the system they want, and can easily add components -themselves for other users to take advantage of. No mutual trust need -exist in advance for users to use each other's services, nor does the -system become vulnerable by trusting the services of arbitrary users. -
- -

-So the Hurd is a set of servers running on top of the Mach -micro-kernel, providing a POSIX compatible and extensible operating -system. What servers are there? What functionality do they provide, -and how do they cooperate? - -

Mach Inter Process Communication

-
-

-Ports are message queues which can be used as one-way communication -channels. -

    -
  • Port rights are receive, send or send-once
    • -
  • Exactly one receiver
    • -
  • Potentially many senders
    • -
-

-MIG provides remote procedure calls on top of Mach IPC. RPCs look like -function calls to the user. -

-

-Inter-process communication in Mach is based on the ports concept. A -port is a message queue, used as a one-way communication channel. In -addition to a port, you need a port right, which can be a send right, -receive right, or send-once right. Depending on the port right, you -are allowed to send messages to the server, receive messages from it, -or send just one single message. -

-For every port, there exists exactly one task holding the receive -right, but there can be no or many senders. The send-once right is -useful for clients expecting a response message. They can give a -send-once right to the reply port along with the message. The kernel -guarantees that at some point, a message will be received on the reply -port (this can be a notification that the server destroyed the -send-once right). -

-You don't need to know much about the format a message takes to be -able to use the Mach IPC. The Mach interface generator mig hides the -details of composing and sending a message, as well as receiving the -reply message. To the user, it just looks like a function call, but -in truth the message could be sent over a network to a server running -on a different computer. The set of remote procedure calls a server -provides is the public interface of this server. - - -

How to get a port?

-
-

-Traditional Mach: -

    -
  • Nameserver provides ports to all registered servers.
    • -
  • The nameserver port itself is provided by Mach.
    • -
  • Like a phone book: One list.
    • -
-

-The Hurd: -

    -
  • The filesystem is used as the server namespace.
    • -
  • Root directory port is inserted into each task.
    • -
  • The C library finds other ports with hurd_file_name_lookup, - performing a pathname resolution.
    • -
  • Like a tree of phone books.
    • -
-
-

-So how does one get a port to a server? You need something like a -phone book for server ports, or otherwise you can only talk to -yourself. In the original Mach system, a special nameserver is -dedicated to that job. A task could get a port to the nameserver from -the Mach kernel and ask it for a port (with send right) to a server -that registered itself with the nameserver at some earlier time. -

-In the Hurd, there is no nameserver. Instead, the filesystem is used -as the server namespace. This works because there is always a root -filesystem in the Hurd (remember that the Hurd is a POSIX compatible -system); this is an assumption the people who developed Mach couldn't -make, so they had to choose a different strategy. You can use the -function hurd_file_name_lookup, which is part of the C library, to get -a port to the server belonging to a filename. Then you can start to -send messages to the server in the usual way. - -

Example of hurd_file_name_lookup

-
-mach_port_t identity;
-mach_port_t pwserver;
-kern_return_t err;
-
-pwserver = hurd_file_name_lookup
-                ("/servers/password");
-
-err = password_check_user (pwserver,
-                           0 /* root */, "supass",
-                           &identity);
-
-

-As a concrete example, the special filename -/servers/password can be used to request a port to the -Hurd password server, which is responsible to check user provided -passwords. -

-(explanation of the example) - -

Pathname resolution example

-
-

-Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem. -

    -
  • The C library asks the root filesystem server about - /mnt/readme.txt.
    • -
  • The root filesystem returns a port to the mnt filesystem server - (matching /mnt) and the retry name - /readme.txt.
    • -
  • The C library asks the mnt filesystem server about - /readme.txt.
    • -
  • The mnt filesystem server returns a port to itself and records - that this port refers to the regular file - /readme.txt.
    • -
-
-

-The C library itself does not have a full list of all available -servers. Instead pathname resolution is used to traverse through a -tree of servers. In fact, filesystems themselves are implemented by -servers (let us ignore the chicken and egg problem here). So all the -C library can do is to ask the root filesystem server about the -filename provided by the user (assuming that the user wants to resolve -an absolute path), using the dir_lookup RPC. If the -filename refers to a regular file or directory on the filesystem, the -root filesystem server just returns a port to itself and records that -this port corresponds to the file or directory in question. But if a -prefix of the full path matches the path of a server the root -filesystem knows about, it returns to the C library a port to this -server and the remaining part of the pathname that couldn't be -resolved. The C library than has to retry and query the other server -about the remaining path component. Eventually, the C library will -either know that the remaining path can't be resolved by the last -server in the list, or get a valid port to the server in question. - -

Mapping the POSIX Interface

-
- - - - - - - - - - - - - - - - - - - -
FiledescriptorPort to server providing the file
fd = open(name,...)dir_lookup(..,name,..,&port)
-[pathname resolution]
read(fd, ...)io_read(port, ...)
write(fd, ...)io_write(port, ...)
fstat(fd, ...)io_stat(port, ...)
...
-
-

-It should by now be obvious that the port returned by the server can -be used to query the files status, content and other information from -the server, if good remote procedure calls to do that are defined and -implemented by it. This is exactly what happens. Whenever a file is -opened using the C libraries open() call, the C library -uses the above pathname resolution to get a port to a server providing -the file. Then it wraps a file descriptor around it. So in the Hurd, -for every open file descriptor there is a port to a server providing -this file. Many other C library calls like read() and -write() just call a corresponding RPC using the port -associated with the file descriptor. - -

File System Servers

-
-
    -
  • Provide file and directory services for ports (and more).
    • -
  • These ports are returned by a directory lookup.
    • -
  • Translate filesystem accesses through their root path (hence the - name translator).
    • -
  • The C library maps the POSIX file and directory interface (and - more) to RPCs to the filesystem servers ports, but also does work on - its own.
    • -
  • Any user can install file system servers on inodes they own.
    • -
-
-

-So we don't have a single phone book listing all servers, but rather a -tree of servers keeping track of each other. That's really like -calling your friend and asking for the phone number of the blond girl -at the party yesterday. He might refer you to a friend who hopefully -knows more about it. Then you have to retry. -

-This mechanism has huge advantages over a single nameserver. First, -note that standard unix permissions on directories can be used to -restrict access to a server (this requires that the filesystems -providing those directories behave). You just have to set the -permissions of a parent directory accordingly and provide no other way -to get a server port. -

-But there are much deeper implications. Most of all, a pathname never -directly refers to a file, it refers to a port of a server. That -means that providing a regular file with static data is just one of -the many options the server has to service requests on the file port. -A server can also create the data dynamically. For example, a server -associated with /dev/random can provide new random data -on every io_read() on the port to it. A server -associated with /dev/fortune can provide a new fortune -cookie on every open(). -

-While a regular filesystem server will just serve the data as stored -in a filesystem on disk, there are servers providing purely virtual -information, or a mixture of both. It is up to the server to behave -and provide consistent and useful data on each remote procedure call. -If it does not, the results may not match the expectations of the user -and confuse him. -

-A footnote from the Hurd info manual: -

-(1) You are lost in a maze of twisty little filesystems, all -alike.... -
-

-Because a server installed in the filesystem namespace translates all -filesystem operations that go through its root path, such a server is -also called "active translator". You can install translators using -the settrans command with the -a option. - -

Active vs Passive

-
-

-Active Translators: -

    -
  • "settrans -a /cdrom /hurd/isofs /dev/hd2"
    • -
  • Are running filesystem servers.
    • -
  • Are attached to the root node they translate.
    • -
  • Run as a normal process.
    • -
  • Go away with every reboot, or even time out.
    • -
-
-

-Many translator settings remain constant for a long time. It would be -very lame to always repeat the same couple of dozens settrans calls -manually or at boot time. So the Hurd provides a filesystem extension -that allows to store translator settings inside the filesystem and let -the filesystem servers do the work to start those servers on demand. -Such translator settings are called "passive translators". A passive -translator is really just a command line string stored in an inode of -the filesystem. If during a pathname resolution a server encounters -such a passive translator, and no active translator does exist already -(for this node), it will use this string to start up a new translator -for this inode, and then let the C library continue with the path -resolution as described above. Passive translators are installed with -settrans using the -p option (which is already the -default). - -
-

-Passive Translators: -

    -
  • "settrans /mnt /hurd/ext2fs /dev/hd1s1"
    • -
  • Are stored as command strings into an inode.
    • -
  • Are used to start a new active translator if there isn't - one.
    • -
  • Startup is transparent to the user.
    • -
  • Startup happens the first time the server is needed.
    • -
  • Are permanent across reboots (like file data).
    • -
-
-

-So passive translators also serve as a sort of automounting feature, -because no manual interaction is required. The server start up is -deferred until the service is need, and it is transparent to the user. -

-When starting up a passive translator, it will run as a normal process -with the same user and group id as those of the underlying inode. Any -user is allowed to install passive and active translators on inodes -that he owns. This way the user can install new servers into the -global namespace (for example, in his home or tmp directory) and thus -extend the functionality of the system (recall that servers can -implement other remote procedure calls beside those used for files and -directories). A careful design of the trusted system servers makes -sure that no permissions leak out. -

-In addition, users can provide their own implementations of some of -the system servers instead the system default. For example, they can -use their own exec server to start processes. The user specific exec -server could for example start java programs transparently (without -invoking the interpreter manually). This is done by setting the -environment variable EXECSERVERS. The systems default -exec server will evaluate this environment variable and forward the -RPC to each of the servers listed in turn, until some server accepts -it and takes over. The system default exec server will only do this -if there are no security implications. (XXX There are other ways to -start new programs than by using the system exec server. Those are -still available.) -

-Let's take a closer look at some of the Hurd servers. It was already -mentioned that only few system servers are mandatory for users. To -establish your identity within the Hurd system, you have to -communicate with the trusted systems authentication server -auth. To put the system administrator into control over -the system components, the process server does some global -bookkeeping. -

-But even these servers can be ignored. However, registration with the -authentication server is the only way to establish your identity -towards other system servers. Likewise, only tasks registered as -processes with the process server can make use of its services. - -

Authentication

-
-

-A user identity is just a port to an authserver. The auth server -stores four set of ids for it: -

    -
  • effective user ids
    • -
  • effective group ids
    • -
  • available user ids
    • -
  • available group ids
    • -
-

-Basic properties: -

    -
  • Any of these can be empty.
    • -
  • A 0 among the user ids identifies the superuser.
    • -
  • Effective ids are used to check if the user has the - permission.
    • -
  • Available ids can be turned into effective ids on user - request.
    • -
-
-

-The Hurd auth server is used to establish the identity of a user for a -server. Such an identity (which is just a port to the auth server) -consists of a set of effective user ids, a set of effective group ids, -a set of available user ids and a set of available group ids. Any of -these sets can be empty. - -

Operations on authentication ports

-
-

-The auth server provides the following operations on ports: -

    -
  • Merge the ids of two ports into a new one.
    • -
  • Return a new port containing a subset of the ids in a port.
    • -
  • Create a new port with arbitrary ids (superuser only).
    • -
  • Establish a trusted connection between users and servers.
    • -
-
-

-If you have two identities, you can merge them and request an identity -consisting of the unions of the sets from the auth server. You can -also create a new identity consisting only of subsets of an identity -you already have. What you can't do is extending your sets, unless -you are the superuser which is denoted by having the user id 0. - -

Establishing trusted connections

-
-
    -
  • User provides a rendezvous port to the server (with - io_reauthenticate).
    • -
  • User calls auth_user_authenticate on the - authentication port (his identity), passing the rendezvous port.
    • -
  • Server calls auth_server_authenticate on its - authentication port (to a trusted auth server), passing the - rendezvous port and the server port.
    • -
  • If both authentication servers are the same, it can match the - rendezvous ports and return the server port to the user and the user - ids to the server.
    • -
-
-

-Finally, the auth server can establish the identity of a user for a -server. This is done by exchanging a server port and a user identity -if both match the same rendezvous port. The server port will be -returned to the user, while the server is informed about the id sets -of the user. The server can then serve or reject subsequent RPCs by -the user on the server port, based on the identity it received from -the auth server. -

-Anyone can write a server conforming to the auth protocol, but of -course all system servers use a trusted system auth server to -establish the identity of a user. If the user is not using the system -auth server, matching the rendezvous port will fail and no server port -will be returned to the user. Because this practically requires all -programs to use the same auth server, the system auth server is -minimal in every respect, and additional functionality is moved -elsewhere, so user freedom is not unnecessarily restricted. - -

Password Server

-
-

-The password server /servers/password runs as root and -returns a new authentication port in exchange for a unix password. -

-The ids corresponding to the authentication port match the unix user -and group ids. -

-Support for shadow passwords is implemented here. -

-

-The password server sits at /servers/password and runs as -root. It can hand out ports to the auth server in exchange for a unix -password, matching it against the password or shadow file. Several -utilities make use of this server, so they don't need to be setuid -root. - -

Process Server

-
-

-The superuser must remain control over user tasks, so: -

    -
  • All mach tasks are associated with a PID in the system default - proc server.
    • -
-

-Optionally, user tasks can store: -

    -
  • Their environment variables.
    • -
  • Their argument vector.
    • -
  • A port, which others can request based on the PID (like a - nameserver).
    • -
-

-Also implemented in the proc server: -

    -
  • Sessions and process groups.
    • -
  • Global configuration not in Mach, like hostname, hostid, system - version.
    • -
-
-

-The process server is responsible for some global bookkeeping. As -such it has to be trusted and is not replaceable by the user. -However, a user is not required to use any of its service. In that -case the user will not be able to take advantage of the POSIXish -appearance of the Hurd. -

-The Mach Tasks are not as heavy as POSIX processes. For example, -there is no concept of process groups or sessions in Mach. The proc -server fills in the gap. It provides a PID for all Mach tasks, and -also stores the argument line, environment variables and other -information about a process (if the mach tasks provide them, which is -usually the case if you start a process with the default -fork()/exec()). A process can also register -a message port with the proc server, which can then be requested by -anyone. So the proc server also functions as a nameserver using the -process id as the name. -

-The proc server also stores some other miscellaneous information not -provided by Mach, like the hostname, hostid and system version. -Finally, it provides facilities to group processes and their ports -together, as well as to convert between pids, process server ports and -mach task ports. -
-

-User tasks not registering themselve with proc only have a PID assigned. -

-Users can run their own proc server in addition to the system default, -at least for those parts of the interface that don't require superuser -privileges. -

-

-Although the system default proc server can't be avoided (all Mach -tasks spawned by users will get a pid assigned, so the system -administrator can control them), users can run their own additional -process servers if they want, implementing the features not requiring -superuser privileges. - -

Filesystems

-
-

-Store based filesystems -

    -
  • ext2fs
    • -
  • ufs
    • -
  • isofs (iso9660, RockRidge, GNU extensions)
    • -
  • fatfs (under development)
    • -
-

-Network file systems -

    -
  • nfs
    • -
  • ftpfs
    • -
-

-Miscellaneous -

    -
  • hostmux
    • -
  • usermux
    • -
  • tmpfs (under development)
    • -
-
-

-We already talked about translators and the file system service they -provide. Currently, we have translators for the ext2, ufs and iso9660 -filesystems. We also have an nfs client and an ftp filesystem. -Especially the latter is intriguing, as it provides transparent access -to ftp servers in the filesystem. Programs can start to move away -from implementing a plethora of network protocols, as the files are -directly available in the filesystem through the standard POSIX file -interface. - - -

Developing the Hurd

-
-

-Over a dozen libraries support the development of new servers. -

-For special server types highly specialized -libraries require only the implementation of a -number of callback functions. -

    -
  • Use libdiskfs for store based filesystems.
    • -
  • Use libnetfs for network filesystems, also for - virtual filesystems.
    • -
  • Use libtrivfs for simple filesystems providing only - a single file or directory.
    • -
-
-

-The Hurd server protocols are complex enough to allow for the -implementation of a POSIX compatible system with GNU extensions. -However, a lot of code can be shared by all or at least similar -servers. For example, all storage based filesystems need to be able to -read and write to a store medium splitted in blocks. The Hurd comes -with several libraries which make it easy to implement new servers. -Also, there are already a lot of examples of different server types in -the Hurd. This makes writing a new server easier. -

-libdiskfs is a library that supports writing store based -filesystems like ext2fs or ufs. It is not very useful for filesystems -which are purely virtual, like /proc or files in -/dev. -

-libnetfs is intended for filesystems which provide a rich -directory hierarchy, but don't use a backing store (for example ftpfs, -nfs). -

-libtrivfs is intended for filesystems which just provide -a single inode or directory. Most servers which are not intended to -provide a filesystem but other services (like -/servers/password) use it to provide a dummy file, so -that file operations on the servers node will not return errors. But -it can also be used to provide meaningful data in a single file, like -a device store or a character device. - -

Store Abstraction

-
-

-Another very useful library is libstore, which is used by all store -based filesystems. It provides a store media abstraction. A store -consists of a store class and a name (which itself can sometimes -contain stores). -

-Primitive store classes: -

    -
  • device store like device:hd2, device:hd0s1, device:fd0
    • -
  • file store like file:/tmp/disk_image
    • -
  • task store like task:PID
    • -
  • zero store like zero:4m (like /dev/zero, of size 4 MB)
    • -
-
-
-

-Composed store classes: -

    -
  • copy store like copy:zero:4m
    • -
  • gunzip/bunzip2 store like gunzip:device:fd0
    • -
  • concat store like concat:device:hd0s2:device:hd1s5
    • -
  • ileave store (RAID-0(2))
    • -
  • remap store like remap:10+20,50+:file:/tmp/blocks
    • -
  • ...
    • -
-

-Wanted: A similar abstraction for streams (based on channels), which -can be used by network and character device servers. -

-

-libstore provides a store abstraction, which is used by -all store based filesystems. The store is determined by a type and a -name, but some store types modify another store rather than providing -a new store, and thus stores can be stacked. For example, the device -store type expects a Mach device, but the remap store expects a list -of blocks to pick from another store, like remap:1+:device:hd2, which -would pick all blocks from hd2 but the first one, which skipped. -Because this functionality is provided in a library, all libstore -using filesystems support many different store kinds, and adding a new -store type is enough to make all store based filesystems support it. - -

Debian GNU/Hurd

-
-

-Goal: -

    -
  • Provide a binary distribution of the Hurd that is easy to - install.
    • -
-

-Constraints: -

    -
  • Use the same source packages as Debian GNU/Linux.
    • -
  • Use the same infrastructure: -
      -
    • Policy
      • -
    • Archive
      • -
    • Bug tracking system
      • -
    • Release process
      • -
    • -
-

-Side Goal: -

    -
  • Prepare Debian for the future: -
      -
    • More flexibility in the base system
      • -
    • Identify dependencies on the Linux kernel
      • -
    • -
-
-

-The Debian distribution of the GNU Hurd that I started in 1998 is -supposed to become a complete binary distribution of the Hurd that is -easy to install. - -

Status of the Debian GNU/Hurd binary archive

-

-See -http://buildd.debian.org/stats/graph.png -for the most current version of the statistic. - -

Status of the Debian infrastructure

-
-

-Plus: -

    -
  • Source packages can identify build and host OS using - dpkg-architecture.
    • -
-

-Minus: -

    -
  • The binary architecture field is insufficient.
    • -
  • The BTS has no architecture tag.
    • -
  • The policy/FHS need (small) Hurd specific extensions.
    • -
-
-

-While good compatibiity can be achieved at the source level, -the binary packages can not always express their relationship -to the available architectures sufficiently. -

-For example, the Linux version of makedev is binary-all, where -a binary-all-linux relationship would be more appropriate. -

-More work has to be done here to fix the tools. - -

Status of the Debian Source archive

-
-
    -
  • Most packages just work.
    • -
  • Maintainers are usually responsive and cooperative.
    • -
  • Turtle, the autobuilder, crunches through the whole list right - now.
    • -
-

-Common pitfalls are POSIX incompatibilities: -

    -
  • Upstream: -
      -
    • Unconditional use of PATH_MAX - (MAXPATHLEN), MAXHOSTNAMELEN.
      • -
    • Unguarded use of Linux kernel features.
      • -
    • Use of legacy interfaces (sys_errlist, - termio).
      • -
    • -
  • Debian: -
      -
    • Unguarded activation of extensions available with Linux.
      • -
    • Low quality patches.
      • -
    • Assuming GNU/Linux in package scripts.
      • -
    • -
-
-

-Most packages are POSIX compatible and can be compiled without -changes on the Hurd. The maintainers of the Debian source packages -are usually very kind, responsiver and helpful. -

-The Turtle autobuilder software (http://turtle.sourceforge.net) -builds the Debian packages on the Hurd automatically. - -

Debian GNU/Hurd: Good idea, bad idea?

-
-

-Upstream benefits: -

    -
  • Software packages become more portable.
    • -
-

-Debian benefits: -

    -
  • Debian becomes more portable.
    • -
  • Maintainers learn about portability and other systems.
    • -
  • Debian gets a lot of public recognition.
    • -
-

-GNU/Hurd benefits: -

    -
  • Large software base.
    • -
  • Great infrastructure.
    • -
  • Nice community to partner with.
    • -
-
-

-The sheet lists the advantages of all groups involved. - -

End

-
-

-Join us at -

-
-

-List of contacts. - -

-Some of these links are at other web sites not maintained by the -FSF. The FSF is not responsible for the content of these other web sites. - -

- -
- -[ - - - English -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001 Marcus Brinkmann <marcus@gnu.org> -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/hurd.mdwn b/hurd.mdwn index 61e83d21..3c65bb4e 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -53,8 +53,6 @@ in the *unstable* branch of the Debian archive. * [[Critique]] - Analysis * [[Hurd_Hacking_Guide]] * [[Concepts]] -* Other resources - * [Docs at gnu.org](http://www.gnu.org/software/hurd/docs.html) # Using diff --git a/hurd/authentication.mdwn b/hurd/authentication.mdwn index cbb164c8..14144d8e 100644 --- a/hurd/authentication.mdwn +++ b/hurd/authentication.mdwn @@ -10,7 +10,7 @@ is included in the section entitled UIDs on the Hurd are separate from processes. A process has [[capabilities|capability]] designating so-called UID vectors that -are implemented by an [[auth]] server. This +are implemented by an [[translator/auth]] server. This makes them easily [[virtualizable|virtualization]]. When a process wishes to gain access to a resource provided by a third diff --git a/hurd/critique.mdwn b/hurd/critique.mdwn index 9770138e..dacd7bb8 100644 --- a/hurd/critique.mdwn +++ b/hurd/critique.mdwn @@ -8,8 +8,8 @@ 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]]."]]"""]] -[[NealWalfield]] and [[MarcusBrinkmann]] wrote a paper titled [*A Critique of -the GNU Hurd Multi-Server Operating +Neal Walfield and Marcus Brinkmann wrote a paper titled [*A Critique of +the GNU Hurd Multi-server Operating System*](http://walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf). This was published in ACM SIGOPS Operating Systems Review in July 2007. This is sometimes referred to as *the critique*. diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index bb37a8be..a8c3a988 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 +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 @@ -8,10 +9,53 @@ 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]]."]]"""]] +# Introductory Material + * [[What_Is_the_GNU_Hurd]] * [[Advantages]] * [[FAQ]] - * + * [[*Towards_a_New_Strategy_of_OS_Design*|hurd-paper]], an architectural + overview by Thomas Bushnell, BSG. + + * [[*The_Hurd*|hurd-talk]], a presentation by Marcus Brinkmann. + + * [[*A_Critique_of_the_GNU_Hurd_Multi-server_Operating_System*|critique]], an + analysis of the GNU Hurd on GNU Mach system, written by Neal Walfield and + Marcus Brinkmann. + +## External + + * [*Examining the Legendary HURD + Kernel*](http://www.informit.com/articles/printerfriendly.aspx?p=1180992), + an article by David Chisnall. + + Also covers a bit of GNU's and the Hurd's history, fundamental techniques + applied, comparisions to other systems. + + +# Development + + * *[[The_GNU_Hurd_Reference_Manual|reference_manual]]*. + + * The *[[Hurd_Hacking_Guide]]*, an introduction to GNU Hurd and Mach + programming by Wolfgang Jährling. + + * [*Manually Bootstrapping a + Translator*](http://walfield.org/pub/people/neal/papers/hurd-misc/manual-bootstrap.txt), + a text by Neal Walfield about how to *manually connect the translator to + the filesystem*. + + * [[*The_Authentication_Server*|auth]], the transcript of a talk about the + details of the authentication mechanisms in the Hurd by Wolfgang Jährling. + + * [*The Mach Paging Interface as Used by the + Hurd*](http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html), a + text by Neal Walfield. + + * In the + [[Position_paper_*Improving_Usability_via_Access_Decomposition_and_Policy*|ng/position_paper]] + Neal Walfield and Marcus Brinkmann give an overview about how a future, + subsequent system may be architected. diff --git a/hurd/documentation/auth.html b/hurd/documentation/auth.html new file mode 100644 index 00000000..487fc1fe --- /dev/null +++ b/hurd/documentation/auth.html @@ -0,0 +1,168 @@ +[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="The Authentication Server, the transcript of a talk about the +details of the authentication mechanisms in the Hurd by Wolfgang Jährling"]] + +

Table of Contents

+ +
+ +

Introduction

+

+In this text, which mostly resembles the talk I gave at Libre Software +Meeting 2002 in Bordeaux, I will describe what the auth server does, +why it is so important and which cool things you can do with it, both +on the programming and the user side. I will also describe related +programs like the password and fakeauth servers. Note that this text +is targeted at programmers who want to understand the auth mechanism +in detail and are already familiar with concepts like Remote Procedure +Calls (RPCs) as well as the way User- and Group-IDs are used in the +POSIX world. + +

+The auth server is a very small server, therefore it gives a useful +example when you want to learn how a server typically looks like. One +reason why it is so small is that the auth interface, which it +implements, consists of only four RPCs. You can find the interface in +hurd/hurd/auth.defs and the server itself in hurd/auth/. + +

How IDs are represented and used

+

+Each process holds (usually) one port to auth (an auth_t in C source, +which actually is a mach_port_t, of course). The purpose of auth is +to manage User-IDs and Group-IDs, which is the reason why users often +will have no choice but to make use of the systems main auth server, +which does not listen on /servers/auth; instead you inherit a port to +auth from your parent process. Each such port is (internally in the +auth server) associated with a set of effective User- and Group-IDs as +well as a set of available User- and Group-IDs. So we have four sets +of IDs in total. The available IDs can be turned into corresponding +effective IDs at any time. + +

+When you send an auth_getids RPC on the port you hold, you will get +information about which IDs are associated with it, so you can figure +out which permissions you have. But how will a server know that you +have these permissions and therefore know which actions (e.g. writing +into file "foo") it is supposed to do on your behalf and which not? +The establishing of a trusted connection to a server works as follows: + +

    +
  1. A user wants a server to know its IDs
    2. +
  2. The user requests a reauthentication from the server
    3. +
  3. In this request the user will include a port
    4. +
  4. Both will hand this port to auth
    5. +
  5. The user uses auth_user_authenticate
    6. +
  6. The server uses auth_server_authenticate
    7. +
  7. The server also passes a new port to auth
    8. +
  8. auth matches these two requests
    9. +
  9. The user gets the new port from auth
    10. +
  10. The server learns about the IDs of the user
    11. +
  11. The user uses the new port for further communication
    12. +
+ +

+We have different RPCs for users and servers because what we pass and +what we get back differs for them: Users get a port, and servers get +the sets of IDs, and have to specify the port which the user will get. + +

+It is interesting to note that auth can match the requests by +comparing two integers, because when you get the same port from two +people, you will have the same mach_port_t (which is nothing but an +integer). + +

+All of this of course only works if they use the same auth server, +which is why I said often you have no choice other than to use the +one main auth server. But this is no serious restriction, as the auth server has +almost no functionality one might want to replace. In fact, there is +one replacement for the default auth implementation, but more on that +later. + +

POSIX and beyond

+

+Before we examine what is possible with this design, let us take a +short look at how the POSIX semantics are implemented on top of this +design. When a program that comes out of POSIX-land asks for its own +effective User- or Group-ID, we will tell it about the first of the +effective IDs. In the same sense, the POSIX real User- or Group-ID is +the first available ID and the POSIX saved User- or Group-ID is the +second available ID, which is why you have the same ID two times in +the available IDs when you log into your GNU/Hurd machine (you can +figure out which IDs you have with the program "ids", that basically +just does an auth_getauth RPC). When you lack one of those IDs (for +example when you have no effective Group-ID), a POSIX program asking +for this particular information will get "-1" as the ID. + +

+But as you can imagine, we can do more than what POSIX specifies. Fox +example, we can modify our permissions. This is always done with the +auth_makeauth RPC. In this RPC, you specify the IDs that should be +associated with the new port. All of these IDs must be associated +with either the port where the RPC is sent to or one of the additional +ports you can specify; an exception is the superuser root, which is +allowed to creat ports that are associated with arbitrary IDs. +Hereby you can convert available into effective IDs. + +

+This opens the door to a bunch of nice features. For example, we have +the addauth program in the Hurd, which makes it possible to add an ID +to either a single process or a group of processes if you hold the ID or know the +appropriate password, and there is a corresponding rmauth program that +removes an ID. So when you are working on your computer with GNU +Emacs and want to edit a system configuration file, you switch to +Emacs' shell-mode, do an "addauth root", enter the password, edit the +file, and when you are done switch back to shell-mode and do "rmauth +root". These programs have some interesting options, and there are +various other programs, for setting the complete list of IDs (setauth) +and so on. + +

Related servers

+

+Finally, I want to explain two servers which are related to auth. The +first is the password server, which listens on /servers/password. If +you pass to it a User- or Group-ID and the correct password for it, it +will return a port to auth to you which is associated with the ID you +passed to it. It can create such a port because it is running as +root. So let us assume you are an FTP server process. You will start +as root, because you want to use port 21 (in this case, "port" does +not refer to a mach_port_t, of course). But then, you can drop all +your permissions so that you run without any ID. This makes it far +less dangerous to communicate with yet unknown users over the +network. But when someone now hands a username and password to you, +you can ask the password server for a new auth port. The password +server will check the data you pass to it, for example by looking into +/etc/shadow, and if it is valid, it will ask the auth server for a new +port. It receives this port from auth and then passes it on to you. +So you have raised your permissions. (And for the very curious: Yes, +we are well aware of the differences between this concept and +capabilities; and we also do have some kinds of capabilities in +various parts of the Hurd.) + +

+My second example is the fakeauth server. It also implements the auth +protocol. It is the part of the fakeroot implementation that gives a +process the impression that it runs as root, even if it doesn't. So +when the process asks fakeauth about its own IDs, fakeauth will tell +the process that it runs as root. But when the process wants to make +use of the authentication protocol described earlier in this text, +fakeauth will forward the request to its own auth server, which will +usually be the systems main auth server, which will then be able to +match the auth_*_authenticate requests. So what fakeauth does is +acting as a proxy auth server that gives someone the impression to run +as root, while not modifying what that one is allowed to do. + +

+At this point, I have said at least most of what can be said about the +auth server and the protocol it implements, so I will finish by saying +that it might be an interesting task (for you) to modify some existing +software to take advantage of the features I described here. diff --git a/hurd/documentation/hurd-paper.html b/hurd/documentation/hurd-paper.html new file mode 100644 index 00000000..15d2daec --- /dev/null +++ b/hurd/documentation/hurd-paper.html @@ -0,0 +1,760 @@ +[[meta copyright="Copyright © 1996, 1997, 1998, 2007, 2008 Free Software +Foundation, Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="Towards a New Strategy of OS Design, an architectural overview by +Thomas Bushnell, BSG."]] + + +This article explains why FSF is developing a new operating system named the +Hurd, which will be a foundation of the whole GNU system. +The Hurd is built +on top of CMU's Mach 3.0 kernel and uses Mach's virtual memory management and +message-passing facilities. +The GNU C Library will provide the Unix system +call interface, and will call the Hurd for needed services it can't provide +itself. +The design and implementation of the Hurd is being lead by Michael +Bushnell, with assistance from Richard Stallman, Roland McGrath, +Jan Brittenson, and others. + +

Part 1: A More Usable Approach to OS Design

+

+The fundamental purpose of an operating system (OS) is to enable a variety of +programs to share a single computer efficiently and productively. +This +demands memory protection, preemptively scheduled timesharing, coordinated +access to I/O peripherals, and other services. +In addition, an OS can allow +several users to share a computer. +In this case, efficiency demands services +that protect users from harming each other, enable them to share without +prior arrangement, and mediate access to physical devices. +

+On today's computer systems, programmers usually implement these goals +through a large program called the kernel. +Since this program must be +accessible to all user programs, it is the natural place to add functionality +to the system. +Since the only model for process interaction is that of +specific, individual services provided by the kernel, no one creates other +places to add functionality. +As time goes by, more and more is added to the +kernel. +

+A traditional system allows users to add components to a kernel only if they +both understand most of it and have a privileged status within the system. +Testing new components requires a much more painful edit-compile-debug cycle +than testing other programs. +It cannot be done while others are using the +system. +Bugs usually cause fatal system crashes, further disrupting others' +use of the system. +The entire kernel is usually non-pageable. +(There are +systems with pageable kernels, but deciding what can be paged is difficult +and error prone. +Usually the mechanisms are complex, making them difficult +to use even when adding simple extensions.) +

+Because of these restrictions, functionality which properly belongs +behind +the wall of a traditional kernel is usually left out of systems unless it is +absolutely mandatory. +Many good ideas, best done with an open/read/write +interface cannot be implemented because of the problems inherent in the +monolithic nature of a traditional system. +Further, even among those with +the endurance to implement new ideas, only those who are privileged users of +their computers can do so. +The software copyright system darkens the mire by +preventing unlicensed people from even reading the kernel source. +

+Some systems have tried to address these difficulties. +Smalltalk-80 and +the Lisp Machine both represented one method of getting around the problem. +System code is not distinguished from user code; all of the system is +accessible to the user and can be changed as need be. +Both systems were +built around languages that facilitated such easy replacement and extension, +and were moderately successful. +But they both were fairly poor at insulating +users and programs from each other, failing one of the principal goals of OS +design. +

+Most projects that use the Mach 3.0 kernel carry on the hard-to-change +tradition of OS design. +The internal structure is different, but the same +heavy barrier between user and system remains. +The single-servers, while +fairly easy to construct, inherit all the deficiencies of the monolithic +kernels. +

+A multi-server divides the kernel functionality up into logical blocks with +well-defined interfaces. +Properly done, it is easier to make changes and add +functionality. +So most multi-server projects do somewhat better. +Much more +of the system is pageable. +You can debug the system more easily. +You can +test new system components without interfering with other users. +But the +wall between user and system remains; no user can cross it without special +privilege. +

+The GNU Hurd, by contrast, is designed to make the area of +system +code as +limited as possible. +Programs are required to communicate only with a few +essential parts of the kernel; the rest of the system is replaceable +dynamically. +Users can use whatever parts of the remainder of the system +they want, and can easily add components themselves for other users to take +advantage of. +No mutual trust need exist in advance for users to use each +other's services, nor does the system become vulnerable by trusting the +services of arbitrary users. +

+This has been done by identifying those system components which users +must +use in order to communicate with each other. +One of these is responsible for +identifying users' identities and is called the + +authentication server. + +In +order to establish each other's identities, programs must communicate, each +with an authentication server they trust. +Another component establishes +control over system components by the superuser, provides global bookkeeping +operations, and is called the + +process server. + +

+Not all user programs need to communicate with the process server; it is only +necessary for programs which require its services. +Likewise, the +authentication server is only necessary for programs that wish to communicate +their identity to another. +None of the remaining services carry any special +status; not the network implementation, the filesystems, the program +execution mechanism (including setuid), or any others. + +

The Translator Mechanism

+

+The Hurd uses Mach ports primarily as methods for communicating between users +and servers. +(A Mach port is a communication point on a Mach task where +messages are sent and received.) Each port implements a particular set of +protocols, representing operations that can be undertaken on the underlying +object represented by the port. +Some of the protocols specified by the Hurd +are the I/O protocol, used for generic I/O operations; the file protocol, +used for filesystem operations; the socket protocol, used for network +operations; and the process protocol, used for manipulating processes et al. +

+Most servers are accessed by opening files. +Normally, when you open a file, +you create a port associated with that file that is owned by the server +that owns the directory containing the file. +For example, a disk-based +filesystem will normally serve a large number of ports, each of which +represents an open file or directory. +When a file is opened, the server +creates a new port, associates it with the file, and returns the port to the +calling program. +

+However, a file can have a +translator +associated with it. +In this case, +rather than return its own port which refers to the contents of the file, the +server executes a translator program associated with that file. +This +translator is given a port to the actual contents of the file, and is then +asked to return a port to the original user to complete the open operation. +

+This mechanism is used for +mount +by having a translator associated with +each mount point. +When a program opens the mount point, the translator (in +this case, a program which understands the disk format of the mounted +filesystem) is executed and returns a port to the program. +After the +translator is started, it need not be run again unless it dies; the parent +filesystem retains a port to the translator to use in further requests. +

+The owner of a file can associate a translator with it without special +permission. +This means that any program can be specified as a translator. +Obviously the system will not work properly if the translator does not +implement the file protocol correctly. +However, the Hurd is constructed so +that the worst possible consequence is an interruptible hang. +

+One way to use translators is to access hierarchically structured data using +the file protocol. +For example, all the complexity of the user interface to +the +ftp +program is removed. +Users need only know that a particular +directory represents FTP and can use all the standard file manipulation +commands (e.g +ls +or +cp) +to access the remote system, rather than learning +a new set. +Similarly, a simple translator could ease the complexity of +tar +or +gzip. +(Such transparent access would have some added cost, but it would +be convenient.) + +

Generic Services

+

+With translators, the filesystem can act as a rendezvous for interfaces which +are not similar to files. +Consider a service which implements some version +of the X protocol, using Mach messages as an underlying transport. +For each +X display, a file can be created with the appropriate program as its +translator. +X clients would open that file. +At that point, few file +operations would be useful (read and write, for example, would be useless), +but new operations ( +XCreateWindow +or +XDrawText) +might become meaningful. +In this case, the filesystem protocol is used only to manipulate +characteristics of the node used for the rendezvous. +The node need not +support I/O operations, though it should reply to any such messages with a +message_not_understood +return code. +

+This translator technique is used to contact most of the services in the Hurd +that are not structured like hierarchical filesystems. +For example, the +password server, which hands out authorization tags in exchange for +passwords, is contacted this way. +Network protocol servers are also +contacted in this fashion. +Roland McGrath thought up this use of translators. + +

Clever Filesystem Pictures

+

+In the Hurd, translators can also be used to present a filesystem-like view +of another part of the filesystem, with some semantics changed. +For example, +it would be nice to have a filesystem that cannot itself be changed, but +nonetheless records changed versions of its files elsewhere. +(This could be +useful for source code management.) +

+The Hurd will have a translator which creates a directory which is a +conceptual union of other directories, with collision resolution rules of +various sorts. +This can be used to present a single directory to users that +contains all the programs they would want to execute. +There are other useful +variations on this theme. + +

What The User Can Do

+

+No translator gains extra privilege by virtue of being hooked into the +filesystem. +Translators run with the uid of the owner of the file being +translated, and can only be set or changed by that owner. +The I/O and +filesystem protocols are carefully designed to allow their use by mutually +untrusting clients and servers. +Indeed, translators are just ordinary +programs. +The GNU C library has a variety of facilities to make common sorts +of translators easier to write. +

+Some translators may need special privileges, such as the password server or +translators which allow setuid execution. +These translators could be run by +anyone, but only if they are set on a root-owned node would they be able to +provide all their services successfully. +This is analogous to letting any +user call the +reboot +system call, but only honoring it if that user is root. + +

Why This Is So Different

+

+What this design provides is completely novel to the Unix world. +Until now, +OSs have kept huge portions of their functionality in the realm of system +code, thus preventing its modification and extension except in extreme need. +Users cannot replace parts of the system in their programs no matter how much +easier that would make their task, and system managers are loath to install +random tweaks off the net into their kernels. +

+In the Hurd, users can change almost all of the things that are decided for +them in advance by traditional systems. +In combination with the tremendous +control given by the Mach kernel over task address spaces and properties, the +Hurd provides a system in which users will, for the first time, be able to +replace parts of the system they dislike, without disrupting other users. +

+Most Mach-based OSs to date have mostly implemented a wider set of the + +same old + +Unix semantics in a new environment. +In contrast, GNU is extending +those semantics to allow users to improve, bypass, or replace them. + + +

Part 2: A Look at Some of the Hurd's Beasts

+

The Authentication Server

+

+One of the Hurd's more central servers is the authentication server. +Each +port to this server identifies a user and is associated by this server with +an +id block. +Each id block contains sets of user and group ids. +Either +set may be empty. +This server is not the same as the password server +referred to above. +

+The authentication server exports three services. +First, it provides simple +boolean operations on authentication ports: given two authentication ports, +this server will provide a third port representing the union of the two sets +of uids and gids. +Second, this server allows any user with a uid of zero to +create an arbitrary authentication port. +Finally, this server provides RPCs +(Remote Procedure Calls between different programs and possibly different +hosts) which allow mutually untrusting clients and servers to establish their +identities and pass initial information on each other. +This is crucial to +the security of the filesystem and I/O protocols. +

+Any user could write a program which implements the authentication protocol; +this does not violate the system's security. +When a service needs to +authenticate a user, it communicates with its trusted authentication server. +If that user is using a different authentication server, the transaction will +fail and the server can refuse to communicate further. +Because, in effect, +this forces all programs on the system to use the same authentication server, +we have designed its interface to make any safe operation possible, and to +include no extraneous operations. +(This is why there is a separate password +server.) +

The Process Server

+

+The process server acts as an information categorization repository. +There +are four main services supported by this server. +First, the process server +keeps track of generic host-level information not handled by the Mach kernel. +For example, the hostname, the hostid, and the system version are maintained +by the process server. +Second, this server maintains the Posix notions of +sessions and process groups, to help out programs that wish to use Posix +features. +

+Third, the process server maintains a one-to-one mapping between Mach tasks +and Hurd processes. +Every task is assigned a pid. +Processes can register a +message port with this server, which can then be given out to any program +which requests it. +This server makes no attempt to keep these message ports +private, so user programs are expected to implement whatever security they +need themselves. +(The GNU C Library provides convenient functions for all +this.) Processes can tell the process server their current `argv' and `envp' +values; this server will then provide, on request, these vectors of arguments +and environment. +This is useful for writing +ps-like +programs and also +makes it easier to hide or change this information. +None of these features +are mandatory. +Programs are free to disregard all of this and never register +themselves with the process server at all. +They will, however, still have a +pid assigned. +

+Finally, the process server implements +process collections, +which are used +to collect a number of process message ports at the same time. +Also, +facilities are provided for converting between pids, process server ports, +and Mach task ports, while ensuring the security of the ports managed. +

+It is important to stress that the process server is optional. +Because of +restrictions in Mach, programs must run as root in order to identify all the +tasks in the system. +But given that, multiple process servers could +co-exist, each with their own clients, giving their own model of the +universe. +Those process server features which do not require root privileges +to be implemented could be done as per-user servers. +The user's hands are +not tied. +

Transparent FTP

+

+Transparent FTP is an intriguing idea whose time has come. +The popular +ange-ftp +package available for GNU Emacs makes access to FTP files +virtually transparent to all the Emacs file manipulation functions. +Transparent FTP does the same thing, but in a system wide fashion. +This +server is not yet written; the details remain to be fleshed out, and will +doubtless change with experience. +

+In a BSD kernel, a transparent FTP filesystem would be no harder to write +than in the Hurd. +But mention the idea to a BSD kernel hacker, and the +response is that ``such a thing doesn't belong in the kernel''. +In a sense, +this is correct. +It violates all the layering principles of such systems to +place such things in the kernel. +The unfortunate side effect, however, is +that the design methodology (which is based on preventing users from changing +things they don't like) is being used to prevent system designers from making +things better. +(Recent BSD kernels make it possible to write a user program +that provides transparent FTP. +An example is +alex, +but it needs to run +with full root privileges.) +

+In the Hurd, there are no obstacles to doing transparent FTP. +A translator +will be provided for the node +/ftp. +The contents of +/ftp +will probably +not be directly listable, though further subdirectories will be. +There will +be a variety of possible formats. +For example, to access files on uunet, one +could + +cd /ftp/ftp.uu.net:anonymous:mib@gnu. + +Or to access files on a remote +account, one might + +cd /ftp/gnu.org:mib:passwd. + +Parts of this +command could be left out and the transparent FTP program would read them +from a user's +.netrc +file. +In the last case, one might just + +cd /ftp/gnu.org; + +when the rest of the data is already in +.netrc. +

+There is no need to do a +cd +first--use any file command. +To find out about +RFC 1097 (the Telnet Subliminal Message Option), just type + +more /ftp/ftp.uu.net/inet/rfc/rfc1097. + +A copy command to a local disk +could be used if the RFC would be read frequently. +

Filesystems

+

+Ordinary filesystems are also being implemented. +The initial release of the +Hurd will contain a filesystem upwardly compatible with the BSD 4.4 Fast File +System. +In addition to the ordinary semantics, it will provide means to +record translators, offer thirty-two bit user ids and group ids, and supply a +new id per file, called the +author +of the file, which can be set by the +owner arbitrarily. +In addition, because users in the Hurd can have multiple +uids (or even none), there is an additional set of permission bits providing +access control for + +unknown user + +(no uids) as distinct from + +known but arbitrary user + +(some uids: the existing +world +category of file +permissions). +

+The Network File System protocol will be implemented using 4.4 BSD as a +starting point. +A log-structured filesystem will also be implemented using +the same ideas as in Sprite, but probably not the same format. +A GNU network +file protocol may be designed in time, or NFS may be extended to remove its +deficiencies. +There will also be various ``little'' filesystems, such as the +MS-DOS filesystem, to help people move files between GNU and other OSs. + +

Terminals

+

+An I/O server will provide the terminal semantics of Posix. +The GNU C +Library has features for keeping track of the controlling terminal and for +arranging to have proper job control signals sent at the proper times, as +well as features for obeying keyboard and hangup signals. +

+Programs will be able to insert a terminal driver into communications +channels in a variety of ways. +Servers like +rlogind +will be able to insert +the terminal protocol onto their network communication port. +Pseudo-terminals will not be necessary, though they will be provided for +backward compatibility with older programs. +No programs in GNU will depend +on them. +

+Nothing about a terminal driver is forced upon users. +A terminal driver +allows a user to get at the underlying communications channel easily, to +bypass itself on an as-needed basis or altogether, or to substitute a +different terminal driver-like program. +In the last case, provided the +alternate program implements the necessary interfaces, it will be used by the +C Library exactly as if it were the ordinary terminal driver. +

+Because of this flexibility, the original terminal driver will not provide +complex line editing features, restricting itself to the behavior found in +Posix and BSD. +In time, there will be a +readline-based +terminal driver, +which will provide complex line-editing features for those users who want +them. +

+The terminal driver will probably not provide good support for the +high-volume, rapid data transmission required by UUCP or SLIP. +Those +programs do not need any of its features. +Instead they will be using the +underlying Mach device ports for terminals, which support moving large +amounts of data efficiently. + +

Executing Programs

+

+The implementation of the +execve +call is spread across three programs. +The +library marshals the argument and environment vectors. +It then sends a +message to the file server that holds the file to be executed. +The file +server checks execute permissions and makes whatever changes it desires in +the exec call. +For example, if the file is marked setuid and the fileserver +has the ability, it will change the user identification of the new image. +The file server also decides if programs which had access to the old task +should continue to have access to the new task. +If the file server is +augmenting permissions, or executing an unreadable image, then the exec needs +to take place in a new Mach task to maintain security. +

+After deciding the policy associated with the new image, the filesystem calls +the exec server to load the task. +This server, using the BFD (Binary File +Descriptor) library, loads the image. +BFD supports a large number of object +file formats; almost any supported format will be executable. +This server +also handles scripts starting with +#!, +running them through the indicated +program. +

+The standard exec server also looks at the environment of the new image; if +it contains a variable +EXECSERVERS +then it uses the programs specified +there as exec servers instead of the system default. +(This is, of course, +not done for execs that the file server has requested be kept secure.) +

+The new image starts running in the GNU C Library, which sends a message to +the exec server to get the arguments, environment, umask, current directory, +etc. +None of this additional state is special to the file or exec servers; +if programs wish, they can use it in a different manner than the Library. + +

New Processes

+

+The +fork +call is implemented almost entirely in the GNU C Library. +The new +task is created by Mach kernel calls. +The C Library arranges to have its +image inherited properly. +The new task is registered with the process server +(though this is not mandatory). +The C Library provides vectors of functions +to be called at fork time: one vector to be called before the fork, one after +in the parent, and one after in the child. +(These features should not be +used to replace the normal fork-calling sequence; it is intended for +libraries which need to close ports or clean up before a fork occurs.) +The C +library will implement both fork calls specified by the draft Posix.4a (the +proposed standard dealing with the threads extension to the real-time +extension). +

+Nothing forces the user to create new tasks this way. +If a program wants to +use almost the normal fork, but with some special characteristics, then it +can do so. +Hooks will be provided by the C Library, or the function can even +be completely replaced. +None of this is possible in a traditional Unix +system. + +

Asynchronous Messages

+

+As mentioned above, the process server maintains a + +message port + +for each +task registered with it. +These ports are public, and are used to send +asynchronous messages to the task. +Signals, for example, are sent to the +message port. +The signal message also provides a port as an indication that +the sender should be trusted to send the signal. +The GNU C Library lists a +variety of ports in a table, each of which identifies a set of signals that +can be sent by anyone who possesses that port. +For example, if the user +possesses the task's kernel port, it is allowed to send any signal. +If the +user possesses a special + +terminal id + +port, it is allowed to send the +keyboard and hangup signals. +Users can add arbitrary new entries into the C +library's signal permissions table. +

+When a process's process group changes, the process server will send it a +message indicating the new process group. +In this case, the process server +proves its authority by providing the task's kernel port. +

+The C library also has messages to add and delete uids currently used by the +process. +If new uids are sent to the program, the library adds them to its +current set, and then exchanges messages with all the I/O servers it knows +about, proving to them its new authorization. +Similarly, a message can +delete uids. +In the latter case, the caller must provide the process's task +port. +(You can't harm a process by giving it extra permission, but you can +harm it by taking permission away.) The Hurd will provide user programs to +send these messages to processes. +For example, the +su +command will be able +to cause all the programs in your current login session, to gain a new uid, +rather than spawn a subshell. +

+The C library will allow programs to add asynchronous messages they wish to +recognize, as well as prevent recognition of the standard set. +

Making It Look Like Unix

+

+The C Library will implement all of the calls from BSD and Posix as well as +some obvious extensions to them. +This enables users to replace those calls +they dislike or bypass them entirely, whereas in Unix the calls must be used +``as they come'' with no alternatives possible. +

+In some environments binary compatibility will also be supported. +This works +by building a special version of the library which is then loaded somewhere +in the address space of the process. +(For example, on a VAX, it would be +tucked in above the stack.) A feature of Mach, called system call +redirection, is then used to trap Unix system calls and turn them into jumps +into this special version of the library. +(On almost all machines, the cost +of such a redirection is very small; this is a highly optimized path in Mach. +On a 386 it's about two dozen instructions. +This is little worse than a +simple procedure call.) +

+Many features of Unix, such as signal masks and vectors, are handled +completely by the library. +This makes such features significantly cheaper +than in Unix. +It is now reasonable to use +sigblock +extensively to protect +critical sections, rather than seeking out some other, less expensive method. + +

Network Protocols

+

+The Hurd will have a library that will make it very easy to port 4.4 BSD +protocol stacks into the Hurd. +This will enable operation, virtually for +free, of all the protocols supported by BSD. +Currently, this includes the +CCITT protocols, the TCP/IP protocols, the Xerox NS protocols, and the ISO +protocols. +

+For optimal performance some work would be necessary to take advantage of +Hurd features that provide for very high speed I/O. +For most protocols this +will require some thought, but not too much time. +The Hurd will run the +TCP/IP protocols as efficiently as possible. +

+As an interesting example of the flexibility of the Hurd design, consider the +case of IP trailers, used extensively in BSD for performance. +While the Hurd +will be willing to send and receive trailers, it will gain fairly little +advantage in doing so because there is no requirement that data be copied and +avoiding copies for page-aligned data is irrelevant. diff --git a/hurd/documentation/hurd-talk.html b/hurd/documentation/hurd-talk.html new file mode 100644 index 00000000..d608e12a --- /dev/null +++ b/hurd/documentation/hurd-talk.html @@ -0,0 +1,1061 @@ +[[meta copyright="Copyright © 2001 Marcus Brinkmann"]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="The Hurd, a presentation by Marcus Brinkmann"]] + + +

Table of Contents

+ +
+

Talk about the Hurd

+

+This talk about the Hurd was written by Marcus Brinkmann for +

    +
  • OSDEM, Brussels, 4. Feb 2001, +
  • Frühjahrsfachgespräche, Cologne, 2. Mar 2001 and +
  • Libre Software Meeting, Bordeaux, 4. Jul 2001. +
+ +

Introduction

+

+When we talk about free software, we usually refer to the free +software licenses. We also need relief from software patents, so our +freedom is not restricted by them. But there is a third type of +freedom we need, and that's user freedom. + +

+Expert users don't take a system as it is. They like to change the +configuration, and they want to run the software that works best for +them. That includes window managers as well as your favourite text +editor. But even on a GNU/Linux system consisting only of free +software, you can not easily use the filesystem format, network +protocol or binary format you want without special privileges. In +traditional unix systems, user freedom is severly restricted by the +system administrator. + +

+The Hurd removes these restrictions from the user. It provides an +user extensible system framework without giving up POSIX compatibility +and the unix security model. Throughout this talk, we will see that +this brings further advantages beside freedom. + +

Overview

+
+ +

+The Hurd is a POSIX compatible multi-server +system operating on top of the GNU Mach microkernel. + +

+Topics: +

    +
  • GNU Mach
    • +
  • The Hurd
    • +
  • Development
    • +
  • Debian GNU/Hurd
    • +
+
+ +

+The Hurd is a POSIX compatible multi-server system operating on top of +the GNU Mach Microkernel. + +

+I will have to explain what GNU Mach is, so we start with that. Then +I will talk about the Hurd's architecture. After that, I will give a +short overview on the Hurd libraries. Finally, I will tell you how +the Debian project is related to the Hurd. + +

Historicals

+ +
+
    +
  • 1983: Richard Stallman founds the GNU project.
    • +
  • 1988: Decision is made to use Mach 3.0 as the kernel.
    • +
  • 1991: Mach 3.0 is released under compatible license.
    • +
  • 1991: Thomas Bushnell, BSG, founds the Hurd project.
    • +
  • 1994: The Hurd boots the first time.
    • +
  • 1997: Version 0.2 of the Hurd is released.

    • +
  • 1998: Debian hurd-i386 archive is created.
    • +
  • 2001: Debian GNU/Hurd snapshot fills three CD images.
    • +
+
+ +

+When Richard Stallman founded the GNU project in 1983, he wanted to +write an operating system consisting only of free software. Very +soon, a lot of the essential tools were implemented, and released +under the GPL. However, one critical piece was missing: The kernel. +

+After considering several alternatives, it was decided not to write a +new kernel from scratch, but to start with the Mach microkernel. This +was in 1988, and it was not before 1991 that Mach was released under a +license allowing the GNU project to distribute it as a part of the +system. +

+In 1998, I started the Debian GNU/Hurd project, and in 2001 the number +of available GNU/Hurd packages fills three CD images. + +

Kernel Architectures

+
+

+Microkernel: +

    +
  • Enforces resource management (paging, scheduling)
    • +
  • Manages tasks
    • +
  • Implements message passing for IPC
    • +
  • Provides basic hardware support
    • +
+

+Monolithic kernel: +

    +
  • No message passing necessary
    • +
  • Rich set of features (filesystems, authentication, network + sockets, POSIX interface, ...)
    • +
+
+

+Microkernels were very popular in the scientific world around that +time. They don't implement a full operating system, but only the +infrastructure needed to enable other tasks to implement most +features. In contrast, monolithical kernels like Linux contain +program code of device drivers, network protocols, process management, +authentication, file systems, POSIX compatible interfaces and much +more. +

+So what are the basic facilities a microkernel provides? In general, +this is resource management and message passing. Resource management, +because the kernel task needs to run in a special privileged mode of +the processor, to be able to manipulate the memory management unit and +perform context switches (also to manage interrupts). Message +passing, because without a basic communication facility the other +tasks could not interact to provide the system services. Some +rudimentary hardware device support is often necessary to bootstrap +the system. So the basic jobs of a microkernel are enforcing the +paging policy (the actual paging can be done by an external pager +task), scheduling, message passing and probably basic hardware device +support. +

+Mach was the obvious choice back then, as it provides a rich set of +interfaces to get the job done. Beside a rather brain-dead device +interface, it provides tasks and threads, a messaging system allowing +synchronous and asynchronous operation and a complex interface for +external pagers. It's certainly not one of the sexiest microkernels +that exist today, but more like a big old mama. The GNU project +maintains its own version of Mach, called GNU Mach, which is based on +Mach 4.0. In addition to the features contained in Mach 4.0, the GNU +version contains many of the Linux 2.0 block device and network card +drivers. +

+A complete treatment of the differences between a microkernel and +monolithical kernel design can not be provided here. But a couple of +advantages of a microkernel design are fairly obvious. + +

Micro vs Monolithic

+
+

+Microkernel +

    +
  • Clear cut responsibilities +
  • Flexibility in operating system design, easier debugging
    • +
  • More stability (less code to break)
    • +
  • New features are not added to the kernel
    • +
+

+Monolithic kernel +

    +
  • Intolerance or creeping featuritis
    • +
  • Danger of spaghetti code
    • +
  • Small changes can have far reaching side effects
    • +
+
+

+Because the system is split up into several components, clean +interfaces have to be developed, and the responsibilities of each part +of the system must be clear. +

+Once a microkernel is written, it can be used as the base for several +different operating systems. Those can even run in parallel which +makes debugging easier. When porting, most of the hardware dependant +code is in the kernel. +

+Much of the code that doesn't need to run in the special kernel mode +of the processor is not part of the kernel, so stability increases +because there is simply less code to break. +

+New features are not added to the kernel, so there is no need to hold +the barrier high for new operating system features. +

+Compare this to a monolithical kernel, where you either suffer from +creeping featuritis or you are intolerant of new features (we see both +in the Linux kernel). +

+Because in a monolithical kernel, all parts of the kernel can access +all data structures in other parts, it is more likely that short cuts +are used to avoid the overhead of a clean interface. This leads to a +simple speed up of the kernel, but also makes it less comprehensible +and more error prone. A small change in one part of the kernel can +break remote other parts. + +

Single Server vs Multi Server

+
+

+Single Server +

    +
  • A single task implements the functionality of the operating system.
    • +
+

+Multi Server +

    +
  • Many tasks cooperate to provide the system's functionality.
    • +
  • One server provides only a small but well-defined part of the + whole system.
    • +
  • The responsibilities are distributed logically among the servers.
    • +
+

+A single-server system is comparable to a monolithic kernel system. It +has similar +advantages and disadvantages. +

+

+There exist a couple of operating systems based on Mach, but they all +have the same disadvantages as a monolithical kernel, because those +operating systems are implemented in one single process running on top +of the kernel. This process provides all the services a monolithical +kernel would provide. This doesn't make a whole lot of sense (the +only advantage is that you can probably run several of such isolated +single servers on the same machine). Those systems are also called +single-server systems. The Hurd is the only usable multi-server +system on top of Mach. In the Hurd, there are many server programs, +each one responsible for a unique service provided by the operating +system. These servers run as Mach tasks, and communicate using the +Mach message passing facilities. One of them does only provide a +small part of the functionality of the system, but together they build +up a complete and functional POSIX compatible operating system. + +

Multi Server is superior, ...

+
+

+Any multi-server has advantages over single-server: +

    +
  • Clear cut responsibilities
    • +
  • More stability: If one server dies, all others remain
    • +
  • Easier development cycle: Testing without reboot (or replacing + running servers), debugging with gdb
    • +
  • Easier to make changes and add new features +
+
+

+Using several servers has many advantages, if done right. If a file +system server for a mounted partition crashes, it doesn't take down +the whole system. Instead the partition is "unmounted", and +you can try to start the server again, probably debugging it this time +with gdb. The system is less prone to errors in individual +components, and over-all stability increases. The functionality of +the system can be extended by writing and starting new servers +dynamically. (Developing these new servers is easier for the reasons +just mentioned.) +

+But even in a multi-server system the barrier between the system and +the users remains, and special privileges are needed to cross it. We +have not achieved user freedom yet. + +

The Hurd even more so.

+
+

+The Hurd goes beyond all this, and allows users to write and run their +servers, too! +

    +
  • Users can replace system servers dynamically with their own + implementations.
    • +
  • Users can decide what parts of the remainder of the system they + want to use.
    • +
  • Users can extend the functionality of the system.
    • +
  • No mutual trust necessary to make use of other users + services.
    • +
  • Security of the system is not harmed by trusting users + services.
    • +
+
+

+To quote Thomas Bushnell, BSG, from his paper +[[``Towards_a_New_Strategy_of_OS_design''_(1996)|hurd-paper]]: +

+The GNU Hurd, by contrast, is designed to make the area of system code +as limited as possible. Programs are required to communicate only +with a few essential parts of the kernel; the rest of the system is +replaceable dynamically. Users can use whatever parts of the +remainder of the system they want, and can easily add components +themselves for other users to take advantage of. No mutual trust need +exist in advance for users to use each other's services, nor does the +system become vulnerable by trusting the services of arbitrary users. +
+ +

+So the Hurd is a set of servers running on top of the Mach +micro-kernel, providing a POSIX compatible and extensible operating +system. What servers are there? What functionality do they provide, +and how do they cooperate? + +

Mach Inter Process Communication

+
+

+Ports are message queues which can be used as one-way communication +channels. +

    +
  • Port rights are receive, send or send-once
    • +
  • Exactly one receiver
    • +
  • Potentially many senders
    • +
+

+MIG provides remote procedure calls on top of Mach IPC. RPCs look like +function calls to the user. +

+

+Inter-process communication in Mach is based on the ports concept. A +port is a message queue, used as a one-way communication channel. In +addition to a port, you need a port right, which can be a send right, +receive right, or send-once right. Depending on the port right, you +are allowed to send messages to the server, receive messages from it, +or send just one single message. +

+For every port, there exists exactly one task holding the receive +right, but there can be no or many senders. The send-once right is +useful for clients expecting a response message. They can give a +send-once right to the reply port along with the message. The kernel +guarantees that at some point, a message will be received on the reply +port (this can be a notification that the server destroyed the +send-once right). +

+You don't need to know much about the format a message takes to be +able to use the Mach IPC. The Mach interface generator mig hides the +details of composing and sending a message, as well as receiving the +reply message. To the user, it just looks like a function call, but +in truth the message could be sent over a network to a server running +on a different computer. The set of remote procedure calls a server +provides is the public interface of this server. + + +

How to get a port?

+
+

+Traditional Mach: +

    +
  • Nameserver provides ports to all registered servers.
    • +
  • The nameserver port itself is provided by Mach.
    • +
  • Like a phone book: One list.
    • +
+

+The Hurd: +

    +
  • The filesystem is used as the server namespace.
    • +
  • Root directory port is inserted into each task.
    • +
  • The C library finds other ports with hurd_file_name_lookup, + performing a pathname resolution.
    • +
  • Like a tree of phone books.
    • +
+
+

+So how does one get a port to a server? You need something like a +phone book for server ports, or otherwise you can only talk to +yourself. In the original Mach system, a special nameserver is +dedicated to that job. A task could get a port to the nameserver from +the Mach kernel and ask it for a port (with send right) to a server +that registered itself with the nameserver at some earlier time. +

+In the Hurd, there is no nameserver. Instead, the filesystem is used +as the server namespace. This works because there is always a root +filesystem in the Hurd (remember that the Hurd is a POSIX compatible +system); this is an assumption the people who developed Mach couldn't +make, so they had to choose a different strategy. You can use the +function hurd_file_name_lookup, which is part of the C library, to get +a port to the server belonging to a filename. Then you can start to +send messages to the server in the usual way. + +

Example of hurd_file_name_lookup

+
+mach_port_t identity;
+mach_port_t pwserver;
+kern_return_t err;
+
+pwserver = hurd_file_name_lookup
+                ("/servers/password");
+
+err = password_check_user (pwserver,
+                           0 /* root */, "supass",
+                           &identity);
+
+

+As a concrete example, the special filename +/servers/password can be used to request a port to the +Hurd password server, which is responsible to check user provided +passwords. +

+(explanation of the example) + +

Pathname resolution example

+
+

+Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem. +

    +
  • The C library asks the root filesystem server about + /mnt/readme.txt.
    • +
  • The root filesystem returns a port to the mnt filesystem server + (matching /mnt) and the retry name + /readme.txt.
    • +
  • The C library asks the mnt filesystem server about + /readme.txt.
    • +
  • The mnt filesystem server returns a port to itself and records + that this port refers to the regular file + /readme.txt.
    • +
+
+

+The C library itself does not have a full list of all available +servers. Instead pathname resolution is used to traverse through a +tree of servers. In fact, filesystems themselves are implemented by +servers (let us ignore the chicken and egg problem here). So all the +C library can do is to ask the root filesystem server about the +filename provided by the user (assuming that the user wants to resolve +an absolute path), using the dir_lookup RPC. If the +filename refers to a regular file or directory on the filesystem, the +root filesystem server just returns a port to itself and records that +this port corresponds to the file or directory in question. But if a +prefix of the full path matches the path of a server the root +filesystem knows about, it returns to the C library a port to this +server and the remaining part of the pathname that couldn't be +resolved. The C library than has to retry and query the other server +about the remaining path component. Eventually, the C library will +either know that the remaining path can't be resolved by the last +server in the list, or get a valid port to the server in question. + +

Mapping the POSIX Interface

+
+ + + + + + + + + + + + + + + + + + + +
FiledescriptorPort to server providing the file
fd = open(name,...)dir_lookup(..,name,..,&port)
+[pathname resolution]
read(fd, ...)io_read(port, ...)
write(fd, ...)io_write(port, ...)
fstat(fd, ...)io_stat(port, ...)
...
+
+

+It should by now be obvious that the port returned by the server can +be used to query the files status, content and other information from +the server, if good remote procedure calls to do that are defined and +implemented by it. This is exactly what happens. Whenever a file is +opened using the C libraries open() call, the C library +uses the above pathname resolution to get a port to a server providing +the file. Then it wraps a file descriptor around it. So in the Hurd, +for every open file descriptor there is a port to a server providing +this file. Many other C library calls like read() and +write() just call a corresponding RPC using the port +associated with the file descriptor. + +

File System Servers

+
+
    +
  • Provide file and directory services for ports (and more).
    • +
  • These ports are returned by a directory lookup.
    • +
  • Translate filesystem accesses through their root path (hence the + name translator).
    • +
  • The C library maps the POSIX file and directory interface (and + more) to RPCs to the filesystem servers ports, but also does work on + its own.
    • +
  • Any user can install file system servers on inodes they own.
    • +
+
+

+So we don't have a single phone book listing all servers, but rather a +tree of servers keeping track of each other. That's really like +calling your friend and asking for the phone number of the blond girl +at the party yesterday. He might refer you to a friend who hopefully +knows more about it. Then you have to retry. +

+This mechanism has huge advantages over a single nameserver. First, +note that standard unix permissions on directories can be used to +restrict access to a server (this requires that the filesystems +providing those directories behave). You just have to set the +permissions of a parent directory accordingly and provide no other way +to get a server port. +

+But there are much deeper implications. Most of all, a pathname never +directly refers to a file, it refers to a port of a server. That +means that providing a regular file with static data is just one of +the many options the server has to service requests on the file port. +A server can also create the data dynamically. For example, a server +associated with /dev/random can provide new random data +on every io_read() on the port to it. A server +associated with /dev/fortune can provide a new fortune +cookie on every open(). +

+While a regular filesystem server will just serve the data as stored +in a filesystem on disk, there are servers providing purely virtual +information, or a mixture of both. It is up to the server to behave +and provide consistent and useful data on each remote procedure call. +If it does not, the results may not match the expectations of the user +and confuse him. +

+A footnote from the Hurd info manual: +

+(1) You are lost in a maze of twisty little filesystems, all +alike.... +
+

+Because a server installed in the filesystem namespace translates all +filesystem operations that go through its root path, such a server is +also called "active translator". You can install translators using +the settrans command with the -a option. + +

Active vs Passive

+
+

+Active Translators: +

    +
  • "settrans -a /cdrom /hurd/isofs /dev/hd2"
    • +
  • Are running filesystem servers.
    • +
  • Are attached to the root node they translate.
    • +
  • Run as a normal process.
    • +
  • Go away with every reboot, or even time out.
    • +
+
+

+Many translator settings remain constant for a long time. It would be +very lame to always repeat the same couple of dozens settrans calls +manually or at boot time. So the Hurd provides a filesystem extension +that allows to store translator settings inside the filesystem and let +the filesystem servers do the work to start those servers on demand. +Such translator settings are called "passive translators". A passive +translator is really just a command line string stored in an inode of +the filesystem. If during a pathname resolution a server encounters +such a passive translator, and no active translator does exist already +(for this node), it will use this string to start up a new translator +for this inode, and then let the C library continue with the path +resolution as described above. Passive translators are installed with +settrans using the -p option (which is already the +default). + +
+

+Passive Translators: +

    +
  • "settrans /mnt /hurd/ext2fs /dev/hd1s1"
    • +
  • Are stored as command strings into an inode.
    • +
  • Are used to start a new active translator if there isn't + one.
    • +
  • Startup is transparent to the user.
    • +
  • Startup happens the first time the server is needed.
    • +
  • Are permanent across reboots (like file data).
    • +
+
+

+So passive translators also serve as a sort of automounting feature, +because no manual interaction is required. The server start up is +deferred until the service is need, and it is transparent to the user. +

+When starting up a passive translator, it will run as a normal process +with the same user and group id as those of the underlying inode. Any +user is allowed to install passive and active translators on inodes +that he owns. This way the user can install new servers into the +global namespace (for example, in his home or tmp directory) and thus +extend the functionality of the system (recall that servers can +implement other remote procedure calls beside those used for files and +directories). A careful design of the trusted system servers makes +sure that no permissions leak out. +

+In addition, users can provide their own implementations of some of +the system servers instead the system default. For example, they can +use their own exec server to start processes. The user specific exec +server could for example start java programs transparently (without +invoking the interpreter manually). This is done by setting the +environment variable EXECSERVERS. The systems default +exec server will evaluate this environment variable and forward the +RPC to each of the servers listed in turn, until some server accepts +it and takes over. The system default exec server will only do this +if there are no security implications. (XXX There are other ways to +start new programs than by using the system exec server. Those are +still available.) +

+Let's take a closer look at some of the Hurd servers. It was already +mentioned that only few system servers are mandatory for users. To +establish your identity within the Hurd system, you have to +communicate with the trusted systems authentication server +auth. To put the system administrator into control over +the system components, the process server does some global +bookkeeping. +

+But even these servers can be ignored. However, registration with the +authentication server is the only way to establish your identity +towards other system servers. Likewise, only tasks registered as +processes with the process server can make use of its services. + +

Authentication

+
+

+A user identity is just a port to an authserver. The auth server +stores four set of ids for it: +

    +
  • effective user ids
    • +
  • effective group ids
    • +
  • available user ids
    • +
  • available group ids
    • +
+

+Basic properties: +

    +
  • Any of these can be empty.
    • +
  • A 0 among the user ids identifies the superuser.
    • +
  • Effective ids are used to check if the user has the + permission.
    • +
  • Available ids can be turned into effective ids on user + request.
    • +
+
+

+The Hurd auth server is used to establish the identity of a user for a +server. Such an identity (which is just a port to the auth server) +consists of a set of effective user ids, a set of effective group ids, +a set of available user ids and a set of available group ids. Any of +these sets can be empty. + +

Operations on authentication ports

+
+

+The auth server provides the following operations on ports: +

    +
  • Merge the ids of two ports into a new one.
    • +
  • Return a new port containing a subset of the ids in a port.
    • +
  • Create a new port with arbitrary ids (superuser only).
    • +
  • Establish a trusted connection between users and servers.
    • +
+
+

+If you have two identities, you can merge them and request an identity +consisting of the unions of the sets from the auth server. You can +also create a new identity consisting only of subsets of an identity +you already have. What you can't do is extending your sets, unless +you are the superuser which is denoted by having the user id 0. + +

Establishing trusted connections

+
+
    +
  • User provides a rendezvous port to the server (with + io_reauthenticate).
    • +
  • User calls auth_user_authenticate on the + authentication port (his identity), passing the rendezvous port.
    • +
  • Server calls auth_server_authenticate on its + authentication port (to a trusted auth server), passing the + rendezvous port and the server port.
    • +
  • If both authentication servers are the same, it can match the + rendezvous ports and return the server port to the user and the user + ids to the server.
    • +
+
+

+Finally, the auth server can establish the identity of a user for a +server. This is done by exchanging a server port and a user identity +if both match the same rendezvous port. The server port will be +returned to the user, while the server is informed about the id sets +of the user. The server can then serve or reject subsequent RPCs by +the user on the server port, based on the identity it received from +the auth server. +

+Anyone can write a server conforming to the auth protocol, but of +course all system servers use a trusted system auth server to +establish the identity of a user. If the user is not using the system +auth server, matching the rendezvous port will fail and no server port +will be returned to the user. Because this practically requires all +programs to use the same auth server, the system auth server is +minimal in every respect, and additional functionality is moved +elsewhere, so user freedom is not unnecessarily restricted. + +

Password Server

+
+

+The password server /servers/password runs as root and +returns a new authentication port in exchange for a unix password. +

+The ids corresponding to the authentication port match the unix user +and group ids. +

+Support for shadow passwords is implemented here. +

+

+The password server sits at /servers/password and runs as +root. It can hand out ports to the auth server in exchange for a unix +password, matching it against the password or shadow file. Several +utilities make use of this server, so they don't need to be setuid +root. + +

Process Server

+
+

+The superuser must remain control over user tasks, so: +

    +
  • All mach tasks are associated with a PID in the system default + proc server.
    • +
+

+Optionally, user tasks can store: +

    +
  • Their environment variables.
    • +
  • Their argument vector.
    • +
  • A port, which others can request based on the PID (like a + nameserver).
    • +
+

+Also implemented in the proc server: +

    +
  • Sessions and process groups.
    • +
  • Global configuration not in Mach, like hostname, hostid, system + version.
    • +
+
+

+The process server is responsible for some global bookkeeping. As +such it has to be trusted and is not replaceable by the user. +However, a user is not required to use any of its service. In that +case the user will not be able to take advantage of the POSIXish +appearance of the Hurd. +

+The Mach Tasks are not as heavy as POSIX processes. For example, +there is no concept of process groups or sessions in Mach. The proc +server fills in the gap. It provides a PID for all Mach tasks, and +also stores the argument line, environment variables and other +information about a process (if the mach tasks provide them, which is +usually the case if you start a process with the default +fork()/exec()). A process can also register +a message port with the proc server, which can then be requested by +anyone. So the proc server also functions as a nameserver using the +process id as the name. +

+The proc server also stores some other miscellaneous information not +provided by Mach, like the hostname, hostid and system version. +Finally, it provides facilities to group processes and their ports +together, as well as to convert between pids, process server ports and +mach task ports. +
+

+User tasks not registering themselve with proc only have a PID assigned. +

+Users can run their own proc server in addition to the system default, +at least for those parts of the interface that don't require superuser +privileges. +

+

+Although the system default proc server can't be avoided (all Mach +tasks spawned by users will get a pid assigned, so the system +administrator can control them), users can run their own additional +process servers if they want, implementing the features not requiring +superuser privileges. + +

Filesystems

+
+

+Store based filesystems +

    +
  • ext2fs
    • +
  • ufs
    • +
  • isofs (iso9660, RockRidge, GNU extensions)
    • +
  • fatfs (under development)
    • +
+

+Network file systems +

    +
  • nfs
    • +
  • ftpfs
    • +
+

+Miscellaneous +

    +
  • hostmux
    • +
  • usermux
    • +
  • tmpfs (under development)
    • +
+
+

+We already talked about translators and the file system service they +provide. Currently, we have translators for the ext2, ufs and iso9660 +filesystems. We also have an nfs client and an ftp filesystem. +Especially the latter is intriguing, as it provides transparent access +to ftp servers in the filesystem. Programs can start to move away +from implementing a plethora of network protocols, as the files are +directly available in the filesystem through the standard POSIX file +interface. + + +

Developing the Hurd

+
+

+Over a dozen libraries support the development of new servers. +

+For special server types highly specialized +libraries require only the implementation of a +number of callback functions. +

    +
  • Use libdiskfs for store based filesystems.
    • +
  • Use libnetfs for network filesystems, also for + virtual filesystems.
    • +
  • Use libtrivfs for simple filesystems providing only + a single file or directory.
    • +
+
+

+The Hurd server protocols are complex enough to allow for the +implementation of a POSIX compatible system with GNU extensions. +However, a lot of code can be shared by all or at least similar +servers. For example, all storage based filesystems need to be able to +read and write to a store medium splitted in blocks. The Hurd comes +with several libraries which make it easy to implement new servers. +Also, there are already a lot of examples of different server types in +the Hurd. This makes writing a new server easier. +

+libdiskfs is a library that supports writing store based +filesystems like ext2fs or ufs. It is not very useful for filesystems +which are purely virtual, like /proc or files in +/dev. +

+libnetfs is intended for filesystems which provide a rich +directory hierarchy, but don't use a backing store (for example ftpfs, +nfs). +

+libtrivfs is intended for filesystems which just provide +a single inode or directory. Most servers which are not intended to +provide a filesystem but other services (like +/servers/password) use it to provide a dummy file, so +that file operations on the servers node will not return errors. But +it can also be used to provide meaningful data in a single file, like +a device store or a character device. + +

Store Abstraction

+
+

+Another very useful library is libstore, which is used by all store +based filesystems. It provides a store media abstraction. A store +consists of a store class and a name (which itself can sometimes +contain stores). +

+Primitive store classes: +

    +
  • device store like device:hd2, device:hd0s1, device:fd0
    • +
  • file store like file:/tmp/disk_image
    • +
  • task store like task:PID
    • +
  • zero store like zero:4m (like /dev/zero, of size 4 MB)
    • +
+
+
+

+Composed store classes: +

    +
  • copy store like copy:zero:4m
    • +
  • gunzip/bunzip2 store like gunzip:device:fd0
    • +
  • concat store like concat:device:hd0s2:device:hd1s5
    • +
  • ileave store (RAID-0(2))
    • +
  • remap store like remap:10+20,50+:file:/tmp/blocks
    • +
  • ...
    • +
+

+Wanted: A similar abstraction for streams (based on channels), which +can be used by network and character device servers. +

+

+libstore provides a store abstraction, which is used by +all store based filesystems. The store is determined by a type and a +name, but some store types modify another store rather than providing +a new store, and thus stores can be stacked. For example, the device +store type expects a Mach device, but the remap store expects a list +of blocks to pick from another store, like remap:1+:device:hd2, which +would pick all blocks from hd2 but the first one, which skipped. +Because this functionality is provided in a library, all libstore +using filesystems support many different store kinds, and adding a new +store type is enough to make all store based filesystems support it. + +

Debian GNU/Hurd

+
+

+Goal: +

    +
  • Provide a binary distribution of the Hurd that is easy to + install.
    • +
+

+Constraints: +

    +
  • Use the same source packages as Debian GNU/Linux.
    • +
  • Use the same infrastructure: +
      +
    • Policy
      • +
    • Archive
      • +
    • Bug tracking system
      • +
    • Release process
      • +
    • +
+

+Side Goal: +

    +
  • Prepare Debian for the future: +
      +
    • More flexibility in the base system
      • +
    • Identify dependencies on the Linux kernel
      • +
    • +
+
+

+The Debian distribution of the GNU Hurd that I started in 1998 is +supposed to become a complete binary distribution of the Hurd that is +easy to install. + +

Status of the Debian GNU/Hurd binary archive

+

+See +http://buildd.debian.org/stats/graph.png +for the most current version of the statistic. + +

Status of the Debian infrastructure

+
+

+Plus: +

    +
  • Source packages can identify build and host OS using + dpkg-architecture.
    • +
+

+Minus: +

    +
  • The binary architecture field is insufficient.
    • +
  • The BTS has no architecture tag.
    • +
  • The policy/FHS need (small) Hurd specific extensions.
    • +
+
+

+While good compatibiity can be achieved at the source level, +the binary packages can not always express their relationship +to the available architectures sufficiently. +

+For example, the Linux version of makedev is binary-all, where +a binary-all-linux relationship would be more appropriate. +

+More work has to be done here to fix the tools. + +

Status of the Debian Source archive

+
+
    +
  • Most packages just work.
    • +
  • Maintainers are usually responsive and cooperative.
    • +
  • Turtle, the autobuilder, crunches through the whole list right + now.
    • +
+

+Common pitfalls are POSIX incompatibilities: +

    +
  • Upstream: +
      +
    • Unconditional use of PATH_MAX + (MAXPATHLEN), MAXHOSTNAMELEN.
      • +
    • Unguarded use of Linux kernel features.
      • +
    • Use of legacy interfaces (sys_errlist, + termio).
      • +
    • +
  • Debian: +
      +
    • Unguarded activation of extensions available with Linux.
      • +
    • Low quality patches.
      • +
    • Assuming GNU/Linux in package scripts.
      • +
    • +
+
+

+Most packages are POSIX compatible and can be compiled without +changes on the Hurd. The maintainers of the Debian source packages +are usually very kind, responsiver and helpful. +

+The Turtle autobuilder software (http://turtle.sourceforge.net) +builds the Debian packages on the Hurd automatically. + +

Debian GNU/Hurd: Good idea, bad idea?

+
+

+Upstream benefits: +

    +
  • Software packages become more portable.
    • +
+

+Debian benefits: +

    +
  • Debian becomes more portable.
    • +
  • Maintainers learn about portability and other systems.
    • +
  • Debian gets a lot of public recognition.
    • +
+

+GNU/Hurd benefits: +

    +
  • Large software base.
    • +
  • Great infrastructure.
    • +
  • Nice community to partner with.
    • +
+
+

+The sheet lists the advantages of all groups involved. + +

End

+
+

+Join us at +

+
+

+List of contacts. diff --git a/hurd/hurd_hacking_guide.mdwn b/hurd/hurd_hacking_guide.mdwn index 0cb96f32..2ef08f8a 100644 --- a/hurd/hurd_hacking_guide.mdwn +++ b/hurd/hurd_hacking_guide.mdwn @@ -8,6 +8,16 @@ 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]]."]]"""]] -Originally written by Wolfgang Jährling, the [Hurd Hacking Guide](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) -contains an overview of some of the Hurd's features. -Also contains a tutorial on writing your own [[translator]]. +Originally written by Wolfgang Jährling, the *Hurd Hacking Guide* contains an +introduction to GNU Hurd and GNU Mach programming, an overview of some of the +Hurd's features. It also contains a tutorial on writing your own +[[translator]]. + + * [HTML version](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) for + browsing online, + * [PostScript version](http://www.gnu.org/software/hurd/hacking-guide/hhg.ps) + [187kB, 37 pages], + * [ASCII text + version](http://www.gnu.org/software/hurd/hacking-guide/hhg.txt) [59kB], + * [Texinfo source](http://www.gnu.org/software/hurd/hacking-guide/hhg.texi) + [60kB]. diff --git a/hurd/ng/position_paper.mdwn b/hurd/ng/position_paper.mdwn index 3240a41d..e0f4bf60 100644 --- a/hurd/ng/position_paper.mdwn +++ b/hurd/ng/position_paper.mdwn @@ -8,7 +8,8 @@ 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]]."]]"""]] -[[NealWalfield]] and [[MarcusBrinkmann]] wrote a paper titled [*Improving -Usability via Access Decomposition and Policy -Refinement*](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf). -This is sometimes referred to as *the position paper*. +Neal Walfield and Marcus Brinkmann wrote a paper titled [*Improving Usability +via Access Decomposition and Policy +Refinement*](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf) +where they give an overview about how a future, subsequent system may be +architected. This is sometimes referred to as *the position paper*. diff --git a/hurd/reference_manual.mdwn b/hurd/reference_manual.mdwn new file mode 100644 index 00000000..5b5bff2d --- /dev/null +++ b/hurd/reference_manual.mdwn @@ -0,0 +1,18 @@ +[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 +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]]."]]"""]] + +*The GNU Hurd Reference Manual* documents the architecture, the usage and the +programming of the GNU Hurd. At the moment, the manual is quite incomplete. + + * [HTML version](http://www.gnu.org/software/hurd/doc/hurd_toc.html) for + browsing online, + * [PostScript version](http://www.gnu.org/software/hurd/doc/hurd.ps) + [1020KiB, 91 pages]. diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index fc42e862..b0a6badd 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -94,7 +94,7 @@ about getting applications to work (if possible). * GNU [Coding Standards](http://www.gnu.org/prep/standards.html) * [[TestSuites]] - Posix, Perl, results feedback, etc. -* [docs and papers](http://www.gnu.org/software/hurd/docs.html) +* [[Documentation]] * [[SystemAPILimits]] * [[CodeAnnouncements]] - Recent coding projects related to the Hurd diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn index 009b26bf..440f1122 100644 --- a/hurd/running/gnu/universal_package_manager.mdwn +++ b/hurd/running/gnu/universal_package_manager.mdwn @@ -127,7 +127,7 @@ OK. I will give you steps. i. Install a GNU System by folowing [[these_instructions|setup]] -ii. Read about GNU Design +ii. Read about GNU Design: [[Towards_a_New_Strategy_of_OS_Design|documentation/hurd-paper]] iii. Read about translators diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index b9952931..889f02a6 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -43,6 +43,7 @@ See some [[examples]] about how to use translators. # Existing Translators +* [[auth]] * [[pfinet]] * [[pflocal]] * [[hostmux]] diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn new file mode 100644 index 00000000..73e7e025 --- /dev/null +++ b/hurd/translator/auth.mdwn @@ -0,0 +1,13 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +[[*The_Authentication_Server*|documentation/auth]], the transcript of a talk +about the details of the authentication mechanisms in the Hurd by Wolfgang +Jährling. diff --git a/microkernel/faq/multiserver_microkernel.mdwn b/microkernel/faq/multiserver_microkernel.mdwn index da690425..68ed332c 100644 --- a/microkernel/faq/multiserver_microkernel.mdwn +++ b/microkernel/faq/multiserver_microkernel.mdwn @@ -22,5 +22,5 @@ use, but now, because the server runs in user space as the user that started it, they may, for instance, mount an FTP filesystem in their home directory. For more information about the design of the Hurd, read the paper by Thomas -Bushnell, BSG: [Towards a new strategy on OS -design](http://www.gnu.org/software/hurd/hurd-paper.html). +Bushnell, BSG: +[[Towards_a_New_Strategy_of_OS_Design|hurd/documentation/hurd-paper]]. diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn index fe870386..f6f2eb79 100644 --- a/microkernel/mach/documentation.mdwn +++ b/microkernel/mach/documentation.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 +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 @@ -11,12 +12,27 @@ is included in the section entitled - [Meet Mach](http://www.stepwise.com/Articles/Technical/MeetMach.html), a summary of Mach's history and main concepts. + * *[[The_GNU_Mach_Reference_Manual|gnu_mach/reference_manual]]*. + - OSF's [Kernel Interface (ps)](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_interface.ps) [Kernel Interface (pdf)](http://shakthimaan.com/downloads/hurd/kernel_interface.pdf) - OSF's [Kernel Principles (ps)](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps) [Kernel Principles (pdf)](http://shakthimaan.com/downloads/hurd/kernel_principles.pdf) + * [*The Unofficial GNU Mach IPC beginner's + guide*](http://hurdextras.nongnu.org/ipc_guide/), an easy introduction to + Inter Process Comunication in the Mach microkernel by Manuel Pavón + Valderrama. + + * [*Mach IPC without + MIG*](http://walfield.org/pub/people/neal/papers/hurd-misc/mach-ipc-without-mig.txt), + an exercise by Neal Walfield *to understand Mach IPC at one of its lowest + application levels*. + + * [*ipc-hello.c*](http://walfield.org/pub/people/neal/papers/hurd-misc/ipc-hello.c): + *Hello world à la mach ipc*. + - [Porting and Modifying the Mach 3.0 Microkernel](http://shakthimaan.com/downloads/hurd/Porting%20and%20Modifying%20the%20Mach%203.0%20Microkernel.pdf) - [An IO System for Mach](http://shakthimaan.com/downloads/hurd/An%20IO%20System%20for%20Mach.pdf) diff --git a/microkernel/mach/gnu_mach.mdwn b/microkernel/mach/gnu_mach.mdwn index cdb43a6f..19e1ea53 100644 --- a/microkernel/mach/gnu_mach.mdwn +++ b/microkernel/mach/gnu_mach.mdwn @@ -71,6 +71,7 @@ GNU/Hurd. # Development + * [[Reference_Manual]] * [[Building]] * [[Debugging]] * [[Boot_Trace]] diff --git a/microkernel/mach/gnu_mach/reference_manual.mdwn b/microkernel/mach/gnu_mach/reference_manual.mdwn new file mode 100644 index 00000000..225ab176 --- /dev/null +++ b/microkernel/mach/gnu_mach/reference_manual.mdwn @@ -0,0 +1,26 @@ +[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 +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]]."]]"""]] + +*The GNU Mach Reference Manual* documents the architecture, the usage and the +programming of the GNU Mach microkernel. At the moment, the manual documents +the interface completely, but is not very useful as a tutorial or introduction +into the Mach architecture. + + * [HTML version](http://www.gnu.org/software/hurd/gnumach-doc/index.html) + for browsing online, + * [PostScript + version](http://www.gnu.org/software/hurd/gnumach-doc/mach.ps) [around + 900KiB], + * [gzipped PostScript + version](http://www.gnu.org/software/hurd/gnumach-doc/mach.ps.gz) + [around 300KiB], + * [PDF version](http://www.gnu.org/software/hurd/gnumach-doc/mach.pdf) + [around 700KiB]. diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index 8c977e55..a0bbbe14 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -66,8 +66,7 @@ pp. 67--77." # Further Relevant Documentation - * The [GNU Mach Reference - Manual](http://www.gnu.org/software/hurd/docs.html#manuals), espacially + * The [[GNU_Mach_Reference_Manual|gnu_mach/reference_manual]], espacially [Chapter 4, Inter Process Communication](http://www.gnu.org/software/hurd/gnumach-doc/Inter-Process-Communication.html), which, for example, explains how the `dealloc` flag -- cgit v1.2.3 From 13433b83cb123607b1eaf7d09f85566f24cea029 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 11:43:27 +0100 Subject: old_hurd_faq.html -> hurd/faq/old_hurd_faq.txt --- hurd/faq/old_hurd_faq.txt | 289 +++++++++++++++++++++++++++++++++++++++++++ old_hurd_faq.html | 306 ---------------------------------------------- 2 files changed, 289 insertions(+), 306 deletions(-) create mode 100644 hurd/faq/old_hurd_faq.txt delete mode 100644 old_hurd_faq.html (limited to 'hurd') diff --git a/hurd/faq/old_hurd_faq.txt b/hurd/faq/old_hurd_faq.txt new file mode 100644 index 00000000..a94a28f4 --- /dev/null +++ b/hurd/faq/old_hurd_faq.txt @@ -0,0 +1,289 @@ +The Unofficial (and no longer maintained) GNU Hurd FAQ, Version 0.13 + +Contributions by: + +Michael I. Bushnell +Len Tower +Trent Fisher +jlr@usoft.spb.su +Remy Card +Louis-Dominique Dubeau + +Original Document by: Derek Upham + + +============================== + +Contents: + +Q0. Where can I get the Unofficial GNU Hurd FAQ? +Q2. Where can I get a copy? +Q3. Why bother writing a new OS when we have Linux and 386/BSD? +Q4. What's all this about Mach 3.0 (and Mach 4.0)? +Q5. Where can I find more information? +Q6. What's a proper machine? +Q7. What sort of machines will run Hurd in the future? +Q8. What is the current development status? +Q9. What sort of system would we have if the Hurd was bootable today? + +============================== + +Q0. Where can I get the Unofficial GNU Hurd FAQ? + +The Unofficial Hurd FAQ (what you are reading now) is occasionally +posted to the USENET newsgroup, gnu.misc.discuss. It is also +available from + + http://www.enci.ucalgary.ca/~gord/hurd/hurd-faq.txt + +If you don't have WWW access, you may send mail to me, Gordon +Matzigkeit with a subject line that reads: + + Subject: send hurd-faq + +You should receive a PGP-signed copy of the current version of this +document in a matter of minutes. + + +Q2. Where can I get a copy? + +To put it simply, you can't. It is still under development (by +Michael Bushnell, Roland McGrath and Miles Bader). It is almost, but +not quite, at the point where you can do real work on it. Keep your +fingers crossed. + +Some people have actually bootstrapped it, but the work is not easy, +and the current snapshot won't work until a new multiserver boot +mechanism is made. + +If you *really* want to try it, beware that it is still pre-alpha +code, and that it will likely crash on you. See Trent Fisher's Hurd +pages (under question 5) for the latest information. + + +Q3. Why bother writing a new OS when we have Linux and 386/BSD? + +For one thing, Linux and BSD don't scale well. Hardware designers are +shifting more and more toward multiprocessor machines for performance, +and standard Unix kernels do not provide much multiprocessor support. +The Hurd, on the other hand, runs on top of the Mach 3.0 micro-kernel +[[1]] from CMU. Mach was designed precisely for multiprocessing +machines, so its portability should carry over nicely to the Hurd. + +In addition, the Hurd will be considerably more flexible and robust +than generic Unix. Wherever possible, Unix kernel features have been +moved into unprivileged space. Once there, anyone who desires can +develop custom replacements for them. Users will be able to write and +use their own file systems, their own `exec' servers, or their own +network protocols if they like, all without disturbing other users. + +The Linux kernel has now been modified to allow user-level file +systems, so there is proof that people will actually use features such +as these. It will be much easier to do under the Hurd, however, +because the Hurd is almost entirely run in user space and because the +various servers are designed for this sort of modification. + + +Q4. What's all this about Mach 3.0 (and Mach 4.0)? + +As mentioned above, Mach is a micro-kernel, written at Carnegie Mellon +University. A more descriptive term might be a greatest-common-factor +kernel, since it provides facilities common to all ``real'' operating +systems, such as memory management, interprocess communication, +processes, and a bunch of other stuff. Unfortunately, the system +calls used to access these facilities are only vaguely related to the +familiar and cherished Unix system calls. There are no "fork", +"wait", or "sleep" system-calls, no SIGHUPs, nothing like that. All +this makes it rather difficult to, say, port GNU Emacs to a Mach box. + +The trick is, of course, to write an emulation library. Unix programs +can then use (what they think are) POSIX system calls and facilities +while they are really using Mach system calls and facilities. + +The simplest way of going about this is to take an ordinary Unix +kernel, open it up, and rip out all the machine-specific guts; any +time the Unix kernel talks to the machine, replace the code with calls +to the Mach micro-kernel. Run this fake kernel on a Mach machine and +you end up with something that looks and acts just like Unix (even to +GNU Emacs). Note that the Unix kernel we have implemented is just one +Really Big Mach program (called a single-server). + +The Hurd, on the other hand, breaks the giant Unix kernel down into +various Mach programs running as daemons. Working in concert with +facilities placed in the C library, these daemons provide all of the +POSIX system-calls and features; from the outside they look just like +a standard Unix kernel. This means that, for practical purposes, +anything that you can port to Linux will also port to the Hurd. + +Of course, if a user wishes to run his own daemons, he can do that as +well.... + +Mach 4.0 is an enhanced version of Mach 3.0, put out by the people at +the University of Utah. They are working on another free operating +system, and part of it includes an enhanced, more flexible version of +Mach. The Hurd has moved to Mach 4.0, which is good, because it is a +lot easier to build than 3.0 was. + +You can find more information on Mach by browsing the Hurd pages given +in the next answer, or by looking at the Project Mach and Flux +homepages at: + +Carnegie Mellon University (for Mach versions before 4.0): + + http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html + +the University of Utah (for Mach 4.0): + + http://www.cs.utah.edu/projects/flux/mach4/html/ + + +Q5. Where can I find more information? + +The June 1995 GNU's Bulletin contains the following official +information: + + The GNU Hurd now runs programs native. We have implemented both + shared libraries using ELF, & the popular `ext2' file system used + by Linux. It can run GCC, `make', Emacs, & most other GNU + utilities. Progress is being made so rapidly that by the time you + read this it probably does much more. It is right on the verge of + being self-hosting (able to run on its own well enough to compile + its own source code, & be used for its own development). We have + much better device supportm [sic] & some new utilities, including a + fancy `ps' & `settrans'. For a complete system we still have much + more work to do, but we will make an alpha release as soon as the + network software is finished & shared libraries have been well + tested. We have a mailing list to announce progress; to be added + to it, ask `hurd-announce-request@gnu.org'. + +The Portland State University CS department (via Trent Fisher) +maintains a WWW server with various Hurd documents, including Michael +Bushnell's Hurd paper, all the collected GNU's Bulletins, and various +announcements posted to "gnu.misc.discuss". The top-level GNU page is + + http://www.cs.pdx.edu/~trent/gnu/gnu.html + +and the Hurd page is + + http://www.cs.pdx.edu/~trent/gnu/hurd/hurd.html + +People in Europe might want to try the GNU WWW server for DESY +Germany, first: + + http://info.desy.de/gnu/www + +This site lacks culled, Hurd-specific information at the moment, but +it does have the last two GNU's Bulletins plus lots of general +information. + +There is a snapshot of the Hurd development tree on +"alpha.gnu.ai.mit.edu" in the "/gnu" directory. It is updated as +significant changes are made, and not guaranteed to run. + +You can subscribe to the Hurd announcement list by sending a request +to "hurd-announce-request@gnu.org". This is a moderated list +for distributing Hurd info to ``all and sundry'', and anyone can join. +In addition, there is a private (invitation-only) list for developers +to coordinate their efforts. It's not even worth thinking about +unless you (a) have a lot of free time on your hands, (b) know Unix +internals and Mach very well, and (c) have a proper machine. + + +Q6. What's a proper machine? + +A ``proper machine'', at the moment, means an x86 box running Mach 3.0 +(or 4.0), with FreeBSD 2.x, NetBSD 1.x, or Linux. + +A single-server OS is no longer required for development because by +the time the Hurd bootstrap mechanism is finished, the Hurd will +probably be self-hosting. + +Linux, FreeBSD, or NetBSD will only be required to splat the Hurd +binaries onto a partition of some sort, and to provide a way of +transferring files to the Hurd until the networking code is ready. + + +Q7. What sort of machines will run Hurd in the future? + +The first thing a prospective Hurd machine needs is a Mach 3.0 port. +According to the most recent "comp.os.mach" FAQ (which hasn't been +updated since February 1994), the following chips have redistributable +Mach micro-kernels and device drivers: + + Intel 80x86 (ISA and PS/2 buses) + Motorola 68000 (Sun 3) + Motorola 88000 (Omron Luna) + DEC Vax + DEC Pmax (DECstation 3100) + DEC Alpha + MIPS R4000 (DECstation 5000 et al.) + IBM RS/6000 + Apple Macintosh + +IBM is planning to run WorkplaceOS (the OS/2 successor) over Mach 3.0 +on the PowerPC chip (closely related to the RS/6000), so the PowerPC +will likely be added to this list soon. The University of Utah has +ported Mach 4.0 to the HP700, but it is not yet stable. + +Sun Sparc machines have a redistributable Mach microkernel, but the +device drivers require a SunOS 4.1.1 source license. + +In addition, any prospective Hurd machine needs a port of the GNU C +library. Version 1.07.4 of the library can handle the following +chips: + + Intel 80x86 (BSD, Dynix, Hurd, SCO, SysV) + Motorola 68000 (HP BSD, NEWS, Sun 4) + MIPS R4000 (Ultrix) + Sun Sparc (Solaris 2, Sun 4) + DEC Alpha (OSF/1, mostly finished) + +So if the next Hurd snapshot is self-hosting, we will be able to run +it (in theory) on Intel 80x86s, Motorola 68000s, MIPS R4000s and DEC +Alphas. + +People who can port the Mach micro-kernel to new architectures are +encouraged to do so. People who can port the GNU C library to new +chips (a much larger group) are also encouraged to do so. You can +help out here without knowing anything about Mach or having any +special machine. Note that once the GNU C library exists for a new +chip, for _any_ OS, making a Hurd port later is simple (and making +ports to other chips becomes easier as well---the effects are +cumulative). + +By current indications, the other hardware requirements (RAM, disk +space, and the like) will be about the same as those of BSD 4.4. + + +Q8. What is the current development status? + +Please see Trent Fisher's Hurd pages for details. + + +Q9. What sort of a system would we have if the Hurd was bootable +today? + +Quite likely, if you already use an end-user system like Linux, +FreeBSD, or NetBSD, you'll be disappointed with the Hurd. It will +take some time before the OS hackers really get to work on +applications and major enhancements. + +But, rest assured, Hurd development should proceed very rapidly. + +Of course, if you think you can help, or you just enjoy neat stuff, +then you'll probably like the Hurd. When you actually understand a +fraction of what's going on behind the scenes, it's very impressive. + +All I'm saying is that I'm not expecting all the Windows '95 users in +the world to switch to the Hurd right away. Wait a little while, +maybe 5-6 years (ample time for GNUStep and Guile to be in use), and +GNU users everywhere will be very happy that the FSF proceeded with +the Hurd. :) + + +============================== + +Footnotes: + +[[1]] Yes, I know that ``micro-kernel'' is about as apt a description +as ``Reduced Instruction Set Chip'', but we're stuck with it. diff --git a/old_hurd_faq.html b/old_hurd_faq.html deleted file mode 100644 index 8162184d..00000000 --- a/old_hurd_faq.html +++ /dev/null @@ -1,306 +0,0 @@ - - -The Unofficial (and no longer maintained) GNU Hurd FAQ, Version 0.13 - - - -

The Unofficial (and no longer maintained) GNU Hurd FAQ, Version 0.13
-
-Contributions by:
-
-Michael I. Bushnell 
-Len Tower 
-Trent Fisher 
-jlr@usoft.spb.su
-Remy Card 
-Louis-Dominique Dubeau 
-
-Original Document by: Derek Upham 
-
-
-==============================
-
-Contents:
-
-Q0.  Where can I get the Unofficial GNU Hurd FAQ?
-Q2.  Where can I get a copy?
-Q3.  Why bother writing a new OS when we have Linux and 386/BSD?
-Q4.  What's all this about Mach 3.0 (and Mach 4.0)?
-Q5.  Where can I find more information?
-Q6.  What's a proper machine?
-Q7.  What sort of machines will run Hurd in the future?
-Q8.  What is the current development status?
-Q9.  What sort of system would we have if the Hurd was bootable today?
-
-==============================
-
-Q0.  Where can I get the Unofficial GNU Hurd FAQ?
-
-The Unofficial Hurd FAQ (what you are reading now) is occasionally
-posted to the USENET newsgroup, gnu.misc.discuss.  It is also
-available from
-
-   http://www.enci.ucalgary.ca/~gord/hurd/hurd-faq.txt
-
-If you don't have WWW access, you may send mail to me, Gordon
-Matzigkeit  with a subject line that reads:
-
-   Subject: send hurd-faq
-
-You should receive a PGP-signed copy of the current version of this
-document in a matter of minutes.
-
-
-Q2.  Where can I get a copy?
-
-To put it simply, you can't.  It is still under development (by
-Michael Bushnell, Roland McGrath and Miles Bader).  It is almost, but
-not quite, at the point where you can do real work on it.  Keep your
-fingers crossed.
-
-Some people have actually bootstrapped it, but the work is not easy,
-and the current snapshot won't work until a new multiserver boot
-mechanism is made.
-
-If you *really* want to try it, beware that it is still pre-alpha
-code, and that it will likely crash on you.  See Trent Fisher's Hurd
-pages (under question 5) for the latest information.
-
-
-Q3.  Why bother writing a new OS when we have Linux and 386/BSD?
-
-For one thing, Linux and BSD don't scale well.  Hardware designers are
-shifting more and more toward multiprocessor machines for performance,
-and standard Unix kernels do not provide much multiprocessor support.
-The Hurd, on the other hand, runs on top of the Mach 3.0 micro-kernel
-[[1]] from CMU.  Mach was designed precisely for multiprocessing
-machines, so its portability should carry over nicely to the Hurd.
-
-In addition, the Hurd will be considerably more flexible and robust
-than generic Unix.  Wherever possible, Unix kernel features have been
-moved into unprivileged space.  Once there, anyone who desires can
-develop custom replacements for them.  Users will be able to write and
-use their own file systems, their own `exec' servers, or their own
-network protocols if they like, all without disturbing other users.
-
-The Linux kernel has now been modified to allow user-level file
-systems, so there is proof that people will actually use features such
-as these.  It will be much easier to do under the Hurd, however,
-because the Hurd is almost entirely run in user space and because the
-various servers are designed for this sort of modification.
-
-
-Q4.  What's all this about Mach 3.0 (and Mach 4.0)?
-
-As mentioned above, Mach is a micro-kernel, written at Carnegie Mellon
-University.  A more descriptive term might be a greatest-common-factor
-kernel, since it provides facilities common to all ``real'' operating
-systems, such as memory management, interprocess communication,
-processes, and a bunch of other stuff.  Unfortunately, the system
-calls used to access these facilities are only vaguely related to the
-familiar and cherished Unix system calls.  There are no "fork",
-"wait", or "sleep" system-calls, no SIGHUPs, nothing like that.  All
-this makes it rather difficult to, say, port GNU Emacs to a Mach box.
-
-The trick is, of course, to write an emulation library.  Unix programs
-can then use (what they think are) POSIX system calls and facilities
-while they are really using Mach system calls and facilities.
-
-The simplest way of going about this is to take an ordinary Unix
-kernel, open it up, and rip out all the machine-specific guts; any
-time the Unix kernel talks to the machine, replace the code with calls
-to the Mach micro-kernel.  Run this fake kernel on a Mach machine and
-you end up with something that looks and acts just like Unix (even to
-GNU Emacs).  Note that the Unix kernel we have implemented is just one
-Really Big Mach program (called a single-server).
-
-The Hurd, on the other hand, breaks the giant Unix kernel down into
-various Mach programs running as daemons.  Working in concert with
-facilities placed in the C library, these daemons provide all of the
-POSIX system-calls and features; from the outside they look just like
-a standard Unix kernel.  This means that, for practical purposes,
-anything that you can port to Linux will also port to the Hurd.
-
-Of course, if a user wishes to run his own daemons, he can do that as
-well....
-
-Mach 4.0 is an enhanced version of Mach 3.0, put out by the people at
-the University of Utah.  They are working on another free operating
-system, and part of it includes an enhanced, more flexible version of
-Mach.  The Hurd has moved to Mach 4.0, which is good, because it is a
-lot easier to build than 3.0 was.
-
-You can find more information on Mach by browsing the Hurd pages given
-in the next answer, or by looking at the Project Mach and Flux
-homepages at:
-
-Carnegie Mellon University (for Mach versions before 4.0):
-
-   http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html
-
-the University of Utah (for Mach 4.0):
-
-   http://www.cs.utah.edu/projects/flux/mach4/html/
-
-
-Q5.  Where can I find more information?
-
-The June 1995 GNU's Bulletin contains the following official
-information:
-
-   The GNU Hurd now runs programs native.  We have implemented both
-   shared libraries using ELF, & the popular `ext2' file system used
-   by Linux.  It can run GCC, `make', Emacs, & most other GNU
-   utilities.  Progress is being made so rapidly that by the time you
-   read this it probably does much more.  It is right on the verge of
-   being self-hosting (able to run on its own well enough to compile
-   its own source code, & be used for its own development).  We have
-   much better device supportm [sic] & some new utilities, including a
-   fancy `ps' & `settrans'.  For a complete system we still have much
-   more work to do, but we will make an alpha release as soon as the
-   network software is finished & shared libraries have been well
-   tested.  We have a mailing list to announce progress; to be added
-   to it, ask `hurd-announce-request@gnu.org'.
-
-The Portland State University CS department (via Trent Fisher)
-maintains a WWW server with various Hurd documents, including Michael
-Bushnell's Hurd paper, all the collected GNU's Bulletins, and various
-announcements posted to "gnu.misc.discuss".  The top-level GNU page is
-
-   http://www.cs.pdx.edu/~trent/gnu/gnu.html
-
-and the Hurd page is
-
-   http://www.cs.pdx.edu/~trent/gnu/hurd/hurd.html
-
-People in Europe might want to try the GNU WWW server for DESY
-Germany, first:
-
-   http://info.desy.de/gnu/www
-
-This site lacks culled, Hurd-specific information at the moment, but
-it does have the last two GNU's Bulletins plus lots of general
-information.
-
-There is a snapshot of the Hurd development tree on
-"alpha.gnu.ai.mit.edu" in the "/gnu" directory.  It is updated as
-significant changes are made, and not guaranteed to run.
-
-You can subscribe to the Hurd announcement list by sending a request
-to "hurd-announce-request@gnu.org".  This is a moderated list
-for distributing Hurd info to ``all and sundry'', and anyone can join.
-In addition, there is a private (invitation-only) list for developers
-to coordinate their efforts.  It's not even worth thinking about
-unless you (a) have a lot of free time on your hands, (b) know Unix
-internals and Mach very well, and (c) have a proper machine.
-
-
-Q6.  What's a proper machine?
-
-A ``proper machine'', at the moment, means an x86 box running Mach 3.0
-(or 4.0), with FreeBSD 2.x, NetBSD 1.x, or Linux.
-
-A single-server OS is no longer required for development because by
-the time the Hurd bootstrap mechanism is finished, the Hurd will
-probably be self-hosting.
-
-Linux, FreeBSD, or NetBSD will only be required to splat the Hurd
-binaries onto a partition of some sort, and to provide a way of
-transferring files to the Hurd until the networking code is ready.
-
-
-Q7.  What sort of machines will run Hurd in the future?
-
-The first thing a prospective Hurd machine needs is a Mach 3.0 port.
-According to the most recent "comp.os.mach" FAQ (which hasn't been
-updated since February 1994), the following chips have redistributable
-Mach micro-kernels and device drivers:
-
-    Intel 80x86         (ISA and PS/2 buses)
-    Motorola 68000      (Sun 3)
-    Motorola 88000      (Omron Luna)
-    DEC Vax
-    DEC Pmax            (DECstation 3100)
-    DEC Alpha
-    MIPS R4000          (DECstation 5000 et al.)
-    IBM RS/6000
-    Apple Macintosh
-
-IBM is planning to run WorkplaceOS (the OS/2 successor) over Mach 3.0
-on the PowerPC chip (closely related to the RS/6000), so the PowerPC
-will likely be added to this list soon.  The University of Utah has
-ported Mach 4.0 to the HP700, but it is not yet stable.
-
-Sun Sparc machines have a redistributable Mach microkernel, but the
-device drivers require a SunOS 4.1.1 source license.
-
-In addition, any prospective Hurd machine needs a port of the GNU C
-library.  Version 1.07.4 of the library can handle the following
-chips:
-
-    Intel 80x86         (BSD, Dynix, Hurd, SCO, SysV)
-    Motorola 68000      (HP BSD, NEWS, Sun 4)
-    MIPS R4000          (Ultrix)
-    Sun Sparc           (Solaris 2, Sun 4)
-    DEC Alpha           (OSF/1, mostly finished)
-
-So if the next Hurd snapshot is self-hosting, we will be able to run
-it (in theory) on Intel 80x86s, Motorola 68000s, MIPS R4000s and DEC
-Alphas.
-
-People who can port the Mach micro-kernel to new architectures are
-encouraged to do so.  People who can port the GNU C library to new
-chips (a much larger group) are also encouraged to do so.  You can
-help out here without knowing anything about Mach or having any
-special machine.  Note that once the GNU C library exists for a new
-chip, for _any_ OS, making a Hurd port later is simple (and making
-ports to other chips becomes easier as well---the effects are
-cumulative).
-
-By current indications, the other hardware requirements (RAM, disk
-space, and the like) will be about the same as those of BSD 4.4.
-
-
-Q8.  What is the current development status?
-
-Please see Trent Fisher's Hurd pages for details.
-
-
-Q9.  What sort of a system would we have if the Hurd was bootable
-today?
-
-Quite likely, if you already use an end-user system like Linux,
-FreeBSD, or NetBSD, you'll be disappointed with the Hurd.  It will
-take some time before the OS hackers really get to work on
-applications and major enhancements.
-
-But, rest assured, Hurd development should proceed very rapidly.
-
-Of course, if you think you can help, or you just enjoy neat stuff,
-then you'll probably like the Hurd.  When you actually understand a
-fraction of what's going on behind the scenes, it's very impressive.
-
-All I'm saying is that I'm not expecting all the Windows '95 users in
-the world to switch to the Hurd right away.  Wait a little while,
-maybe 5-6 years (ample time for GNUStep and Guile to be in use), and
-GNU users everywhere will be very happy that the FSF proceeded with
-the Hurd. :)
-
-
-==============================
-
-Footnotes:
-
-[[1]] Yes, I know that ``micro-kernel'' is about as apt a description
-as ``Reduced Instruction Set Chip'', but we're stuck with it.
-
-
-

-Updated: - -23 Feb 1998 grat-w - -

- - - -- cgit v1.2.3 From 2213166ab5b58cf89f3b07eded20ab2a03d9c681 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 12:10:57 +0100 Subject: Integrate hurd-and-linux.html. --- hurd-and-linux.html | 104 --------------------------------- hurd/documentation.mdwn | 2 + hurd/documentation/hurd-and-linux.html | 47 +++++++++++++++ 3 files changed, 49 insertions(+), 104 deletions(-) delete mode 100644 hurd-and-linux.html create mode 100644 hurd/documentation/hurd-and-linux.html (limited to 'hurd') diff --git a/hurd-and-linux.html b/hurd-and-linux.html deleted file mode 100644 index d9181d88..00000000 --- a/hurd-and-linux.html +++ /dev/null @@ -1,104 +0,0 @@ - - - -The Hurd and Linux - GNU Project - Free Software Foundation (FSF) - - - - - -

The Hurd and Linux

-[ - - - Chinese(Simplified) -| Chinese(Traditional) -| Hebrew -| English -| Spanish -] - -

-by Richard Stallman. - -

- -People sometimes ask, ``Why did the FSF develop a new free kernel -instead of using Linux?'' It's a reasonable question. The answer, -briefly, is that that is not the question we faced. - -

-When we started developing the Hurd in 1990, the question facing us -was, ``How can we get a free kernel for the GNU system?'' There was -no free Unix-like kernel then, and we knew of no other plan to write -one. The only way we could expect to have a free kernel was to write -it ourselves. So we started. - -

-We heard about Linux after its release. At that time, the question -facing us was, ``Should we cancel the Hurd project and use Linux -instead?'' - -

-We heard that Linux was not at all portable (this may not be true -today, but that's what we heard then). And we heard that Linux was -architecturally on a par with the Unix kernel; our work was leading to -something much more powerful. - -

-Given the years of work we had already put into the Hurd, we decided -to finish it rather than throw them away. - -

-If we did face the question that people ask---if Linux were already -available, and we were considering whether to start writing another -kernel---we would not do it. Instead we would choose another project, -something to do a job that no existing free software can do. - -

-But we did start the Hurd, back then, and now we have made it work. -We hope its superior architecture will make free operating systems -more powerful. - -

- -[ - - - Chinese(Simplified) -| Chinese(Traditional) -| Hebrew -| English -| Spanish -] - -
- -Return to GNU's home page. -

-FSF & GNU inquiries & questions to -gnu@gnu.org. -Other ways to contact the FSF. -

-Comments on these web pages to -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. - -

-Updated: - -$Date$ $Author$ - -

- -
- - diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index a8c3a988..a32bc84f 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -17,6 +17,8 @@ is included in the section entitled * [[FAQ]] + * [[*The_Hurd_and_Linux*|hurd-and-linux]], a comment by Richard Stallman. + * [[*Towards_a_New_Strategy_of_OS_Design*|hurd-paper]], an architectural overview by Thomas Bushnell, BSG. diff --git a/hurd/documentation/hurd-and-linux.html b/hurd/documentation/hurd-and-linux.html new file mode 100644 index 00000000..8eccd62c --- /dev/null +++ b/hurd/documentation/hurd-and-linux.html @@ -0,0 +1,47 @@ +[[meta copyright="Copyright © 1996, 1997, 1998, 2008 Free Software Foundation, +Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="The Hurd and Linux"]] + +by Richard Stallman. + +

+People sometimes ask, ``Why did the FSF develop a new free kernel +instead of using Linux?'' It's a reasonable question. The answer, +briefly, is that that is not the question we faced. + +

+When we started developing the Hurd in 1990, the question facing us +was, ``How can we get a free kernel for the GNU system?'' There was +no free Unix-like kernel then, and we knew of no other plan to write +one. The only way we could expect to have a free kernel was to write +it ourselves. So we started. + +

+We heard about Linux after its release. At that time, the question +facing us was, ``Should we cancel the Hurd project and use Linux +instead?'' + +

+We heard that Linux was not at all portable (this may not be true +today, but that's what we heard then). And we heard that Linux was +architecturally on a par with the Unix kernel; our work was leading to +something much more powerful. + +

+Given the years of work we had already put into the Hurd, we decided +to finish it rather than throw them away. + +

+If we did face the question that people ask---if Linux were already +available, and we were considering whether to start writing another +kernel---we would not do it. Instead we would choose another project, +something to do a job that no existing free software can do. + +

+But we did start the Hurd, back then, and now we have made it work. +We hope its superior architecture will make free operating systems +more powerful. -- cgit v1.2.3 From 4b35c398ab01c2e5ecf49d9fccc44c215f850a0e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 12:29:44 +0100 Subject: Integrate history.html and hurd-announcements.html, plus all Hurd flashes and announcements. --- history.html | 199 -------------------------------------------- hurd-announce | 47 ----------- hurd-announce2 | 143 ------------------------------- hurd-announcements.html | 114 ------------------------- hurd-flash | 22 ----- hurd-flash10 | 25 ------ hurd-flash11 | 25 ------ hurd-flash12 | 76 ----------------- hurd-flash13 | 120 -------------------------- hurd-flash14 | 62 -------------- hurd-flash15 | 60 ------------- hurd-flash2 | 152 --------------------------------- hurd-flash3 | 77 ----------------- hurd-flash4 | 101 ---------------------- hurd-flash5 | 23 ----- hurd-flash6 | 46 ---------- hurd-flash7 | 17 ---- hurd-flash8 | 73 ---------------- hurd-flash9 | 39 --------- hurd/history.mdwn | 81 +++++++++++++++++- hurd/history/hurd-announce | 47 +++++++++++ hurd/history/hurd-announce2 | 143 +++++++++++++++++++++++++++++++ hurd/history/hurd-flash | 22 +++++ hurd/history/hurd-flash10 | 25 ++++++ hurd/history/hurd-flash11 | 25 ++++++ hurd/history/hurd-flash12 | 76 +++++++++++++++++ hurd/history/hurd-flash13 | 120 ++++++++++++++++++++++++++ hurd/history/hurd-flash14 | 62 ++++++++++++++ hurd/history/hurd-flash15 | 60 +++++++++++++ hurd/history/hurd-flash2 | 152 +++++++++++++++++++++++++++++++++ hurd/history/hurd-flash3 | 77 +++++++++++++++++ hurd/history/hurd-flash4 | 101 ++++++++++++++++++++++ hurd/history/hurd-flash5 | 23 +++++ hurd/history/hurd-flash6 | 46 ++++++++++ hurd/history/hurd-flash7 | 17 ++++ hurd/history/hurd-flash8 | 73 ++++++++++++++++ hurd/history/hurd-flash9 | 39 +++++++++ 37 files changed, 1186 insertions(+), 1424 deletions(-) delete mode 100644 history.html delete mode 100644 hurd-announce delete mode 100644 hurd-announce2 delete mode 100644 hurd-announcements.html delete mode 100644 hurd-flash delete mode 100644 hurd-flash10 delete mode 100644 hurd-flash11 delete mode 100644 hurd-flash12 delete mode 100644 hurd-flash13 delete mode 100644 hurd-flash14 delete mode 100644 hurd-flash15 delete mode 100644 hurd-flash2 delete mode 100644 hurd-flash3 delete mode 100644 hurd-flash4 delete mode 100644 hurd-flash5 delete mode 100644 hurd-flash6 delete mode 100644 hurd-flash7 delete mode 100644 hurd-flash8 delete mode 100644 hurd-flash9 create mode 100644 hurd/history/hurd-announce create mode 100644 hurd/history/hurd-announce2 create mode 100644 hurd/history/hurd-flash create mode 100644 hurd/history/hurd-flash10 create mode 100644 hurd/history/hurd-flash11 create mode 100644 hurd/history/hurd-flash12 create mode 100644 hurd/history/hurd-flash13 create mode 100644 hurd/history/hurd-flash14 create mode 100644 hurd/history/hurd-flash15 create mode 100644 hurd/history/hurd-flash2 create mode 100644 hurd/history/hurd-flash3 create mode 100644 hurd/history/hurd-flash4 create mode 100644 hurd/history/hurd-flash5 create mode 100644 hurd/history/hurd-flash6 create mode 100644 hurd/history/hurd-flash7 create mode 100644 hurd/history/hurd-flash8 create mode 100644 hurd/history/hurd-flash9 (limited to 'hurd') diff --git a/history.html b/history.html deleted file mode 100644 index bde11d8e..00000000 --- a/history.html +++ /dev/null @@ -1,199 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Esperanto -| Hebrew -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

How it started

-

-Richard Stallman (RMS) started GNU in 1983, as a project to create a -complete free operating system. In the text of the GNU Manifesto, he -mentioned that there is a primitive kernel. In the first GNUsletter, -Feb. 1986, he says that GNU's kernel is TRIX, which was developed at -the Massachusetts Institute of Technology. - -

-By December of 1986, the Free Software Foundation (FSF) had "started -working on the changes needed to TRIX" [Gnusletter, Jan. 1987]. -Shortly thereafter, the FSF began "negotiating with Professor Rashid -of Carnegie-Mellon University about working with them on the -development of the Mach kernel" [Gnusletter, June, 1987]. The text -implies that the FSF wanted to use someone else's work, rather than -have to fix TRIX. - -

-In [Gnusletter, Feb. 1988], RMS was talking about taking Mach and -putting the Berkeley Sprite filesystem on top of it, "after the parts -of Berkeley Unix... have been replaced." - -

-Six months later, the FSF is saying that "if we can't get Mach, we'll -use TRIX or Berkeley's Sprite." Here, they present Sprite as a -full-kernel option, rather than just a filesystem. - -

-In January, 1990, they say "we aren't doing any kernel work. It does -not make sense for us to start a kernel project now, when we still -hope to use Mach" [Gnusletter, Jan. 1990]. Nothing significant occurs -until 1991, when a more detailed plan is announced: - -

-We are still interested in a multi-process kernel running on top of -Mach. The CMU lawyers are currently deciding if they can release Mach -with distribution conditions that will enable us to distribute it. If -they decide to do so, then we will probably start work. CMU has -available under the same terms as Mach a single-server partial Unix -emulator named Poe; it is rather slow and provides minimal -functionality. We would probably begin by extending Poe to provide -full functionality. Later we hope to have a modular emulator divided -into multiple processes. [Gnusletter, Jan. 1991]. -
- -

-RMS explains the relationship between the Hurd and Linux in The Hurd and Linux, where he mentions -that the FSF started developing the Hurd in 1990. As of [Gnusletter, -Nov. 1991], the Hurd (running on Mach) is GNU's official kernel. - -

Announcements

-
-
-Release 0.2 announcement (complete GNU system)
-
-Release 0.2 announcement (Hurd)
-
-Test release announcement (Aug 96)
-
-Test release status (Jul 96)
-
-Binary image available, Apr 96
-
-This and NetBSD boot flopies should -be enough to get a working GNU/Hurd system!
-
-New Snapshot, Apr 96 -- NFS and lots else -works!
-
-News Flash, Nov 95 -- ftp works!
-
-New Snapshot, Jul 95 -- ext2fs support
-
-New Snapshot, Apr 95
-
-News flash, Nov 94
-
-News flash, Sep 94 -- gcc runs!
-
-News flash, Aug 94
-
-News flash, Jul 94 -- emacs runs!
-
-News flash, May 94
-
-News flash, Apr 94 -- it boots!
-
-GNU Hurd announcement, Nov 93
-
-GNU Hurd announcement, May 91
-
- -
- -

- -[ - - - English -| Esperanto -| Hebrew -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/hurd-announce b/hurd-announce deleted file mode 100644 index 2f165ad8..00000000 --- a/hurd-announce +++ /dev/null @@ -1,47 +0,0 @@ -From mib@PREP.AI.MIT.EDU Tue May 7 12:07:53 1991 -From: mib@PREP.AI.MIT.EDU -Newsgroups: gnu.announce -Subject: FSF work on a GNU OS -Date: 6 May 91 22:15:22 GMT -Reply-To: mib@prep.ai.mit.edu -Distribution: gnu -Organization: GNUs Not Usenet - -The Free Software Foundation is beginning work on a GNU operating -system built on top of the Mach 3.0 microkernel. There are three -goals to this project worth noting: - -o Binary compatability with 4.4 BSD, and other U*x or U*xish systems - on other hardware where appropriate, convenient, and consistent with - the design; - -o Posix compliance (in combination with the GNU C Library and the GNU - C Compiler); and - -o Ease of use as well as several new features and functionality. - - -I am interested in constructive criticism on the interfaces, design, -and implementation from experts in the field of OS research and design -consistent with the above goals. Advice from seasoned U*x hackers is -especially welcome. - -We have a mailing list for discussion. Currently there is little -discussion on the group; the major contributors to the ideas behind -the design all live in the Boston area at this point, and work has -been done via face-to-face communication. I would like to open the -field of discussion to a broader base, both to get wider dissemination -of the ideas behind the current design, as well as to get a greater -breadth of criticism. Periodic postings are currently made to the -mailing list containing a snapshot of the interfaces used by the -various pieces of the system. I would like to see discussion as well; -perhaps we need a critical mass to get this. - -Interested individuals should send me email. I don't regularly read -the newsgroups to which this message is posted. - - -[U*x is an abbreviation for a well-known trademark of AT&T. :-)] - - -mib - diff --git a/hurd-announce2 b/hurd-announce2 deleted file mode 100644 index dce41c43..00000000 --- a/hurd-announce2 +++ /dev/null @@ -1,143 +0,0 @@ -From mib@gnu.ai.mit.edu Wed Nov 3 21:51:03 1993 -Path: usenet.ee.pdx.edu!cs.uoregon.edu!ogicse!emory!nigel.msen.com!sdd.hp.com!swrinde!cs.utexas.edu!uunet!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!prep.ai.mit.edu!gnulists -From: mib@gnu.ai.mit.edu (Michael I Bushnell) -Newsgroups: gnu.announce,gnu.misc.discuss -Subject: Hurd status and call for volunteers -Message-ID: <9311020719.AA02206@geech.gnu.ai.mit.edu> -Date: 1 Nov 93 21:19:05 GMT -Article-I.D.: geech.9311020719.AA02206 -Followup-To: gnu.misc.discuss -Distribution: world -Lines: 124 -Approved: info-gnu@prep.ai.mit.edu -To: info-gnu@prep.ai.mit.edu -X-Shopping-List: - (1) Chaotic casino griddles (2) Cervical congestion (3) Neoclassical - consoles -Xref: usenet.ee.pdx.edu gnu.announce:160 gnu.misc.discuss:3985 - -This message to help sate curiosity, as well as to ask for volunteers. -Until we are ready for alpha test, this is the last such message that -will be posted here. If you want to receive further such messages, -send mail to hurd-ann-request@gnu.ai.mit.edu and ask to be put on that -(moderated) announcements list. - - -What is already done with the Hurd: - -The filesystem is complete; it runs (read-only), and most of its calls -have been tested and work. The filesystem is able to download -programs, by a kludge similar to the kludge used to enable the kernel -to download the first task. In the actual bootstap sequence, it will -download the execserver. - -The proc and auth servers are completed; the exec server is nearly -complete (for a.out, not for bfd). - -C library support for Mach and Hurd rpc stubs, and some of the mach -and hurd specific code, is done. Much untested and probably wrong -code has been written to implement Unix "system calls". A large piece -of this (the descriptor management code) is believed by Roland to have -some architectural flaw, but he isn't sure. - -Some small filesystem servers (shadow directories, for example) have -been written, but have not been compiled, let alone tested. - - -There are currently three things happening wrt the Hurd: - -I am spending nearly all my time getting things to boot and run. My -work is currently directed toward that goal; in the immediate present -I am working with Roland on getting the library in its near-final -state (which will last a long time) to make compiling easier. It is -because this is nearly done that I can send this message. - -Roland is working on the library. Most of the remaining architectural -work is done and being tested. Then Roland will work on integrating -cthreads (which is mostly busywork), miscellaneous filesystem calls, -and then file descriptors. After that comes signals. - -Jan Brittenson will be working on the network server library. This is -a library that, when linked against a BSD protocol stack, will produce -a Hurd network server. (Such a server implements the socket interface -in socket.defs.) - - -There are four general tasks that can be done by other people: - -1. Completing the existing work on the terminal driver. The existing -work implements most of the logic you already associate with a Posixy -terminal driver; it needs the port management and buffering logic -added. - -2. Writing a readline terminal driver. We will want, as an -alternative to the Posixy terminal driver, a readline type terminal -driver. - -3. Writing miscellaneous shell utilities. Here we need shell -utilities to create translators, etc. They should have a nice rich -set of features to do all kinds of GNU things. - -4. Writing miscellaneous filesystem servers. Here we need a -transparent tar server, a transparent FTP server, and the like. - - -Future plans for work to be written by me (once the bootstrap works, -and in addition to testing library code as Roland finishes it): - -o split the existing filesystem into three parts: - o a library for port management for complicated multi-threaded - servers; - o a library for "normal" disk-based filesystems; - o ufs specific code. - -o Write the PF_FILE socket server (what you know as PF_UNIX). - -o Finish the posixy terminal driver if nobody else has. - -o Write miscellaneous shell utilities that nobody else has. - -o Build a self-hosting system. - - -What you need in order to be able to help now: - -o A 386 PC running Mach 3.0. If you have some other kind of hardware, - then you need to port the GNU C library support first. I'm not - entirely sure how much work that involves; you will need to contact - Roland. It might be too much trouble at this point to spend any - effort on it. It's best if it's a machine for which a free port of - Mach is available, though you could do useful work even if it's not. - - If you are not currently running Mach 3.0 with somebody's - single-server, then it is very unlikely you could help, unless you - have a Unix source license. In that case, you could talk to CMU - (write mach@cs.cmu.edu) to find out how to get Mach 3.0 running on - your machine. It is not possible to do development without a Unix - emulator of some kind; just bare Mach 3.0 is not sufficient. I have - neither the time nor knowledge to help someone get a 3.0 - single-server system running. - -o Clue. I don't have enough time to explain operating systems or Unix - to people. You need to have an iron-clad grasp of Unix semantics - (specificaly BSD); it's essential that things be exactly right from - that standpoint. It's not enough that you've programmed Unix - before; you need to understand all the nits. However, you may - disregard my previous comments about a "two question limit". You do - need the ability to intuit to some extent, however. - -o Time. It's not good for me to delegate a task and then have nothing - happen on it. If you have a full-time job where you can't justify - Hurd work as part of your job, you might find that you don't really - have as much time as you thought. Please make sure you really have - enough time before volunteering for a task. - -o Efficient net access. Without a real Internet connection (mail only - is not sufficient), it will be impossible for you to do development - right now. - - -If you think you can help, send me email. If you don't think you can -help right now, then don't give up: the list of conditions will change -as the list of delegatable tasks changes. - diff --git a/hurd-announcements.html b/hurd-announcements.html deleted file mode 100644 index ab3fbad5..00000000 --- a/hurd-announcements.html +++ /dev/null @@ -1,114 +0,0 @@ - - - - - - Hurd Announcements - Free Software Foundation (FSF) - - - - - -

Current and Past Announcements

- -These are all the announcements made over the years. Most of them were -either sent to gnu.announce or Hurd interest -mailing lists. - -
- -
-Release 0.2 announcement (complete GNU system)
- -
-Release 0.2 announcement (Hurd)
- -
-Test release announcement (Aug 96)
- -
-Test release status (Jul 96)
- -
-Binary image available, Apr 96
- -
-This and NetBSD boot flopies should -be enough to get a working Hurd system!
- -
-New Snapshot, Apr 96 -- NFS and lots else -works!
- -
-News Flash, Nov 95 -- ftp works!
- -
-New Snapshot, Jul 95 -- ext2fs support
- -
-New Snapshot, Apr 95
- -
-News flash, Nov 94
- -
-News flash, Sep 94 -- gcc runs!
- -
-News flash, Aug 94
- -
-News flash, Jul 94 -- emacs runs!
- -
-News flash, May 94
- -
-News flash, Apr 94 -- it boots!
- -
-GNU Hurd announcement, Nov 93
- -
-GNU Hurd announcement, May 91
- -
 
- -
- -Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 1998, 1999 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved.

-Updated: - -23 Jan 1999 matthias - -

- - - - diff --git a/hurd-flash b/hurd-flash deleted file mode 100644 index d1bacc79..00000000 --- a/hurd-flash +++ /dev/null @@ -1,22 +0,0 @@ -Path: gnurd!usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!swrinde!gatech!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mib -From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell) -Newsgroups: gnu.misc.discuss,comp.os.mach -Subject: Hurd now bootstraps -Date: 05 Apr 1994 21:49:50 GMT -Organization: Free Software Foundation, Cambridge, MA -Lines: 11 -Message-ID: -NNTP-Posting-Host: churchy.gnu.ai.mit.edu - - -The GNU Hurd now bootstraps, successfully starting the core servers -(the filesystem, exec server, process server, auth server, and init) -and running the first program. A snapshot of the code that did this -is on alpha.gnu.ai.mit.edu in the usual place, /gnu/hurd-snap.tar.gz. - --- -+1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David, -+1 617 253 8568 (W) -+- and Jonathan loved him as his own soul. -1105 Broadway | Then Jonathan made a covenant with David -Somerville, MA 02144 | because he loved him as his own soul. - diff --git a/hurd-flash10 b/hurd-flash10 deleted file mode 100644 index d6d5685b..00000000 --- a/hurd-flash10 +++ /dev/null @@ -1,25 +0,0 @@ -Date: Mon, 15 Apr 1996 15:28:29 -0400 -Message-Id: <199604151928.PAA00636@geech.gnu.ai.mit.edu> -From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) -To: hurd-ann@gnu.ai.mit.edu -Subject: New Hurd snapshot available -X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+ -+$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv -+ b+++ !D B-- e+ u++(*) h* f? r n y++ -X-Tom-Swiftie: "Use the `&' operator to get the address," Tom pointed out. -Sender: owner-abshurd@cs.pdx.edu -Precedence: bulk - - -I have just cut a new source snapshot. If things go nicely, a binary -snapshot may appear soon as well. You can find this snapshot as - -ftp://alpha.gnu.ai.mit.edu/gnu/hurd-snap-960415.tar.gz - -Many many things work! Emacs built native and just *went*. The -system now works standalone; you can use gdb (it's much nicer than -other mach-ish gdb's, of course); the network is functional (complete -with NFS), etc. - -Michael - diff --git a/hurd-flash11 b/hurd-flash11 deleted file mode 100644 index 57851b01..00000000 --- a/hurd-flash11 +++ /dev/null @@ -1,25 +0,0 @@ -From: Miles Bader -To: hurd-ann@gnu.ai.mit.edu -Date: Thu, 18 Apr 1996 19:08:07 -0400 -Subject: hurd binary image - - -A filesystem image from a working hurd system, corresponding to the latest -snapshot, is available as: - - ftp://alpha.gnu.ai.mit.edu/gnu/hurd-image-960418.tar.gz - -The whole tree takes about 37meg (warning -- it unpacks into `.'). Follow -the instructions in ./INSTALL-binary to make a working hurd system. - -Due to a timely trashing of the disk on our main hurd machine, it has been -verified that it is possible to make a bootable hurd system from scratch -using this image and a set of netbsd 1.1 boot floppies... - -The sources for the mach kernel included in the image are available in the -same directory as mach4-UK22.tar.gz and mach4-i386-UK22.tar.gz. - --Miles --- -Miles Bader / miles@gnu.ai.mit.edu / (617) 253-8568 -Amadera e ike! diff --git a/hurd-flash12 b/hurd-flash12 deleted file mode 100644 index 5be9c94e..00000000 --- a/hurd-flash12 +++ /dev/null @@ -1,76 +0,0 @@ -From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) -Newsgroups: gnu.misc.discuss -Subject: Hurd 0.0 release status -Followup-To: gnu.misc.discuss -Date: 13 Jul 1996 23:53:41 GMT -Organization: Touring Consulting Services -Lines: 35 -Message-ID: -NNTP-Posting-Host: churchy.gnu.ai.mit.edu - - -People are eager to know how close we are to release, so here's an -update: - -There is one rather annoying bug I'd like to find which is causing -random crashes. I expect this will not be too hard to locate. There -are some more trivial bugs, but the release will not be held up for -them. - -Forty-three packages of GNU software have been built native. -Remaining to be built are three packages for which new releases are -expected soon. - -Also remaining to be built native are bash, gdb, mach, the Hurd -itself, and the internet utilities and daemons. We intend to sync our -separate copy of libc source with the libc maintainer, and then build -it native too. - -Because of obnoxious export restrictions, we have still to make -separate shared libraries for the crypt functions. - -Except for the actual final packaging, all the release engineering -tasks to be done have been completed. - - -To summarize, we still need to: - -o Fix one obnoxious bug -o Compile three packages that are waiting for release; -o Compile gdb, bash, mach, and hurd native -o Sync libc source and compile native -o Deal with crypt shared libraries -o Final packaging - -Michael - -From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) -Newsgroups: gnu.misc.discuss -Subject: Re: Hurd--ne plus ultra of vaporware? -Date: 17 Jul 1996 03:02:14 GMT - -In article <4sg6tp$n4t@linux.cs.Helsinki.FI> torvalds@linux.cs.Helsinki.FI (Linus Torvalds) writes: - - Hey! We could also ask some well-known rock-group for one of their - lyrics, and use that as the theme song for the Hurd release. And then - we could ask shops to stay open longer to sell the Hurd! Whaddaya think? - Don't say it has been delayed, just shout so loudly about all the new - features that nobody cares about the delay? - -Perhaps we could get Morrisey to sing the song. He's very good -looking. Much better looking than that Mick Jagger fellow. - -Or something delicate, like Bach's French Suite in G. That would be -fun. - -In any case, here's the state of the release: - -o Everything but nine packages has been compiled native. -o The random crash bug I alluded to is fixed. -o We have to build a floppy image for part of the installation instructions. - -That's it. I bet you nobody in Redmond has ever made a statement like -that... - -Michael - diff --git a/hurd-flash13 b/hurd-flash13 deleted file mode 100644 index a2de6bfd..00000000 --- a/hurd-flash13 +++ /dev/null @@ -1,120 +0,0 @@ -Date: Mon, 5 Aug 1996 22:36:31 -0400 -From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) -To: info-gnu@prep.ai.mit.edu, hurd-ann@gnu.ai.mit.edu, hurd-dev@gnu.ai.mit.edu -Subject: Hurd 0.0 and GNU 0.0 released -X-Name-Change: My name used to be `Michael'; now it is `Thomas'. -X-Tom-Swiftie: "I guess I shouldn't have broken the mirror," Tom reflected. - - - - -I am pleased to announce version 0.0 of the GNU Hurd, available via -anonymous FTP from prep.ai.mit.edu [18.159.0.42] in the file -/pub/gnu/hurd-0.0.tar.gz (about 1.2 MB compressed). - -This file contains complete source code for the following: - -Hurd servers: - - auth, crash, devio, devport, exec, ext2fs, fifo, fwd, ifsock, init, - magic, new-fifo, nfs, null, pfinet, pflocal, proc, symlink, term, - ufs. - -Hurd libraries: - - diskfs, fshelp, ihash, iohelp, netfs, pager, pipe, ports, ps, - shouldbeinlibc, store, threads, trivfs. - -Hurd utilities and other programs: - - boot, shd, ps, settrans, showtrans, sync, su, mount, fsysopts, - storeinfo, login, w, uptime, hurdids, loginpr, sush, vmstat, - portinfo, devprobe, reboot, halt, fsck, fsck.ufs, mkfs.ufs, clri.ufs, - stati.ufs, getty, rc. - - ------- - - -In addition, we have prepared a binary distribution of a complete -version 0.0 GNU system corresponding to this Hurd release. This -release runs only on PC-AT compatible systems with i[345]86 -processors. - -The GNU Hurd, plus Mach, is a kernel, not an operating system. The -GNU operating system, like the Unix operating system, consists of many -components, including kernel, libraries, compilers, assembler, shell, -parser generators, utilities, window system, editors, text formatters, -and so on. The GNU project set out a decade ago to develop this -system, and we've been writing various components of it ever since. - -This release uses the `UK22' version of the Mach kernel, as -distributed by the University of Utah. It is too difficult to prepare -a detailed list of supported devices at this point. Common disk -controllers and ethernet cards are generally supported. - -This release does not contain the X Window System. - -This release may be fetched by anonymous FTP from prep.ai.mit.edu -[18.159.42] in the directory /pub/gnu/gnu-0.0/. - -In that directory, you should find the following files: - - README - SOURCES - INSTALL-binary - grub-boot.image (about 1.4 MB, not compressed) - gnu-0.0.tar.gz (about 56.9 MB compressed) - gnu-0.0-stripped.tar.gz (about 26.2 MB compressed) - -SOURCES contains a complete list describing the sources for the -binaries found in the image. INSTALL-binary contains complete -installation instructions for this release. - -(The files README, SOURCES, and INSTALL-binary are also found in the -root directory of the gnu-0.0 release.) - -gnu-0.0.tar.gz holds the image of the complete system. It unpacks -into a directory that requires approximately 233 MB of disk space. - -gnu-0.0-stripped.tar.gz holds the same contents as gnu-0.0, except -that executable programs have been stripped to save space, and the -libraries have had debugging symbols stripped to save space and speed -linking. It unpacks into a directory that requires about 85.5 MB of -disk space. - -We recommend using the unstripped image, or you will be unable to -debug anything. Surely there are bugs. So fetch the unstripped -image, at least to have around. - -grub-boot.image is an image of a 3.5" floppy disk that you will need -in order to complete part of the installation instructions. - -The following free software packages are found in this release: - - autoconf, automake, bash, bc, binutils, bison, cpio, cvs, diffutils, - doschk, e2fsprogs, ed, emacs, fileutils, findutils, flex, from, gawk, - gcal, gcc, gdb, gdbm, gettext, glibc, gmp, gperf, grep, grub, gzip, - hello, hurd, indent, inetutils, less, mach, make, m4, miscfiles, - ncurses, nethack, nvi, patch, ptx, rcs, readline, recode, sed, - serverboot, sharutils, shellutils, tar, termcap, termutils, texinfo, - textutils, time, wdiff. - - ------- - - -Here are md5sum checksums for the files mentioned in this message: - -b5f888bab3eb193fe97a00a141324c9d INSTALL-binary -345dcd826747d7b11fc78f4db162d75b README -1a5744bb4ed3448045fa6d24153d65fe SOURCES -f7b1bc428bc4ee29977a5b28f5762092 gnu-0.0-stripped.tar.gz -24554c58e5c89f295176e17d21dbae8e gnu-0.0.tar.gz -8338c619d860b71bc4128c9c0fd39d63 grub-boot.image -1fd18ccc4c81d051b83d28b13dc07ee2 hurd-0.0.tar.gz - ------ - -Br. Thomas Bushnell, n/BSG - diff --git a/hurd-flash14 b/hurd-flash14 deleted file mode 100644 index 2d67687a..00000000 --- a/hurd-flash14 +++ /dev/null @@ -1,62 +0,0 @@ -I am pleased to announce version 0.2 of the GNU Hurd, available via -anonymous FTP from prep.ai.mit.edu [18.159.0.42] in the file -/pub/gnu/hurd-0.2.tar.gz (about 1.37 MB compressed). - -(The GNU Hurd, plus Mach, is a kernel, not an operating system. The -GNU operating system, like the Unix operating system, consists of many -components, including kernel, libraries, compilers, assembler, shell, -parser generators, utilities, window system, editors, text formatters, -and so on. The GNU project set out a decade ago to develop this -system, and we've been writing various components of it ever since.) - -This release contains many bug fixes from version 0.1. Many thanks to -all the people who are helping find bugs! - -The best way you can help find bugs is to try and compile and use on -the Hurd as many programs as you can find and find out where bugs -still exist. There are also unimplemented features, and your reports -will help us to prioritize which things we work on. - -The system is vastly more reliable than it has been in the past. - -One important addition: - - New programs addauth, rmauth, unsu, su, and setauth modify the uid - sets of running programs. Using addauth you can add root to your - emacs, write a file, and then use rmauth to take the uid back. (Of - course, passwords are required when necessary.) New program `ids' - will tell you what all the user ids are that a program has. Note - that in the Hurd a program can have several user ids all at once, - just like Unix supports having several group ids. Now that you can - dynamically change the ids of running programs, system - administration (among other things) becomes much easier. - -For more detailed news, see the NEWS file in the distribution. - -This release contains complete source code for the following: - -Hurd servers: - - auth, crash, devport, exec, ext2fs, fifo, fwd, ifsock, init, - magic, new-fifo, nfs, null, pfinet, pflocal, proc, symlink, term, - ufs, storeio, firmlink. - -Hurd libraries: - - diskfs, fshelp, ihash, iohelp, netfs, pager, pipe, ports, ps, - shouldbeinlibc, store, threads, trivfs, hurdbugaddr, ftpconn - -Hurd utilities and other programs: - - boot, shd, ps, settrans, showtrans, sync, su, mount, fsysopts, - storeinfo, login, w, uptime, ids, sush, vmstat, portinfo, devprobe, - reboot, halt, fsck, fsck.ufs, mkfs.ufs, clri.ufs, stati.ufs, getty, - rc, e2os, vminfo, nfsd, mail.local, serverboot, MAKEDEV, loginpr, - addauth, rmauth, unsu, setauth, ftpcp, ftpdir. - -We are also making a complete GNU 0.2 binary release, which will -include Hurd 0.2, glibc 2.0.4, gnumach 1.1.2, and many other -programs. This binary release is announced separately. - - -Thomas Bushnell, n/BSG diff --git a/hurd-flash15 b/hurd-flash15 deleted file mode 100644 index 0785ac59..00000000 --- a/hurd-flash15 +++ /dev/null @@ -1,60 +0,0 @@ - -I am pleased to announce version 0.2 of the complete Hurd based GNU -system. This release runs only on PC-AT compatible systems with -i[3456]86 processors. - -The GNU Hurd, plus Mach, is a kernel, not an operating system. The -GNU operating system, like the Unix operating system, consists of many -components, including kernel, libraries, compilers, assembler, shell, -parser generators, utilities, window system, editors, text formatters, -and so on. The GNU project set out a decade ago to develop this -system, and we've been writing various components of it ever since. - -This release uses the GNUmach distribution of the Mach kernel, version -1.1.3. Popular PC devices are generally supported. - -This release does not contain the X Window System. - -This release may be fetched from the directory -ftp://prep.ai.mit.edu/pub/gnu/gnu-0.2. (prep.ai.mit.edu is 18.159.42, -for the nameserver-impaired). - -In that directory, you should find the following files: - -README -SOURCES -INSTALL-binary -grub-boot.image (about 1.5 MB, not compressed) -gnu-0.2.tar.gz (about 73 MB compressed) - -SOURCES contains a complete list describing the sources for the -binaries found in the image. INSTALL-binary contains complete -installation instructions for this release. - -(The files README, SOURCES, and INSTALL-binary are also found in the -root directory of the gnu-0.2 release.) - -gnu-0.2.tar.gz holds the image of the complete system. It unpacks -into a directory that requires approximately 285 MB of disk space. - -grub-boot.image is an image of a 3.5" floppy disk that you will need -in order to complete part of the installation instructions. - -The following free software packages are included in this release: - -autoconf automake bash bc binutils bison cpio cvs diffutils doschk -e2fsprogs ed emacs emacs lisp manual fileutils findutils flex from g77 -gawk gcal gcc gdb gettext glibc gmp gnuchess gnumach gnugo grep grub -gzip hello hurd indent inetutils less libg++ lynx m4 make miscfiles -ncurses nethack nvi patch perl ptx readline rcs recode sed sendmail -sh-utils sharutils tar termutils texinfo textutils time wdiff - --- - -Here are md5sum checksums for the files mentioned in this message: - -3749b016ab581e007b90d17b9092e134 INSTALL-binary -1f800c326ba4c3a0b3f3a3463597317b README -40d1e1a38dd86f28fe2718081ac865cb SOURCES -f29c1a03c1667a8019b66f6effa89d39 gnu-0.2.tar.gz -8ad3c7254802a16068a956e836266212 grub-boot.image diff --git a/hurd-flash2 b/hurd-flash2 deleted file mode 100644 index b1d4f66f..00000000 --- a/hurd-flash2 +++ /dev/null @@ -1,152 +0,0 @@ -From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell) -Newsgroups: gnu.misc.discuss,comp.os.mach,comp.os.linux.development,comp.os.linux.misc,comp.unix.pc-clone.32bit -Subject: GNU Hurd Task List and Call for Volunteers -Followup-To: gnu.misc.discuss -Date: 18 May 1994 17:54:47 GMT -Organization: FOO -Lines: 140 -Message-ID: -NNTP-Posting-Host: churchy.gnu.ai.mit.edu -Xref: usenet.ee.pdx.edu gnu.misc.discuss:7630 comp.os.mach:1434 comp.os.linux.d -evelopment:9867 comp.os.linux.misc:16767 comp.unix.pc-clone.32bit:5854 - - -Now that the Hurd can run (albeit haltingly) on its own, it is -possible for people who do not have Mach 3.0 single-servers to -contribute without much trouble. (However, if you don't have a -single-server, you probably won't be able to use a debugger, but that -doesn't mean you can't do debugging, right?) - -We at the FSF don't have any expertise in setting up Mach 3.0 -machines; the machines that we do development on belong to the Open -Software Foundation and were set up by them. So one of the things on -the task list is to organize things so that people (like us and most -of you) who don't know how to do it can do it. It's not impossible to -figure out, it's just a pain and a marvelous thing for a volunteer to -do. - -You can get Mach 3.0 from CMU; you get the C library and the Hurd from -us. You need the soon-to-be-released version 1.07.6 of the C library -and the latest Hurd snapshot (as well as our special version of MiG) -from alpha.gnu.ai.mit.edu. - -All our work is based upon i386. The Hurd (except for a few programs; -see the Hurd README file) is machine independent. The C library -should not be too much trouble to port. Ports and information about -porting difficulty for either of these are greatly desired. - -The Hurd is not yet self-hosting. While you are welcome to fetch the -code and put things together, it is not likely that you will have a -useful system right now. But you might be able to do significant work -(see the task list below). And, even if you can't do significant -work, I'm interested in hearing about any places where you had -particular difficulty. - -If you want to start on one of these tasks, please let me know so I -can keep track of volunteers properly. This task list will be updated -periodically; gnu@prep.ai.mit.edu always has the latest version. - - -mib - -GNU Hurd Task List Version 1.0. - -If you would like to work on one of these, please contact mib@gnu.ai.mit.edu. - - -Mach 3.0 Work - - o Mach 3.0 comes with CMU makefiles that depend on a drecky environment. - It would be very helpful to have makefiles and installation stuff so - that it worked well for cross-compilation between systems and used - GNU tools. - - o MiG needs to be made able to support cross-compilation. - - o A replacement for MiG that understood C .h files. - - o Bootstrap tools and documentation to help people set up Mach 3.0 - machines if they already have Linux; if they already have Net BSD; - if they don't have anything. - - o Mach 3.0 needs to provide support for task virtual timers similar - in functionality to the Unix ITIMER_PROF and ITIMER_VIRTUAL timers. - - o Mach 3.0 needs to provide a way for users to do statistical PC - profiling similar to the Unix profil system call. - - o Mach 3.0 needs a facility to automatically send task and thread - status on task/thread exit to a port that can only be changed by - a privileged user; this would be used to implement process - accounting. - - o Mach 3.0 needs a facility to find out what task is the parent of - a given task. - - o Mach 3.0 needs a facility to find out which pages of a task's - address space are in core to implement Unix's mincore call. - - o Mach 3.0 needs a facility to do msync. - - o Mach 3.0 needs a replacement for MEMORY_OBJECT_COPY_CALL that - works at least for the cases needed in ordinary files. (Write mib if - you want to know what the problem is and some ideas about how to - solve it.) - - o Mach 3.0 needs proxy memory objects. (mib can tell you what these - are and why they are important.) - - o Mach 3.0 needs a way to do per-task resource counters that are - accessible to servers called by the task. - - o Mach 3.0 needs facilities to implement resource limits of various sorts. - - o Mach 3.0 needs a way to have a thread's CPU time statistics - include time spent by servers on its behalf. - - o Of course, free ports are always necessary to machines that don't - already have free ports. - - o Much work can be done doing research in how to improve Mach VM - performance and timesharing scheduling policy. - - -Hurd work (these are brief descriptions; mib can give more information): - - o We need a translator for /dev. - - o We need a replacement for utmp and wtmp that understands the - Hurd `login collection' concept. Programs like who and finger - then need to be changed to use this. - - o We need some existing shell programs changed to do Hurd things: - like ls, su, fsck, tar, cpio, etc. - - o Some new programs need to be written: login, getty, ps, tools - for new filesystem features. - - o Shadow directory translators. (Roland has the beginnings of this.) - - o A system for write, send, talkd and so forth to bleep users; - this should be integrated with the utmp replacement above. - - o X. - - o A filesystem for /tmp that uses virtual memory instead of disk. - - o Filesystem implementations (using libdiskfs) for other popular - formats, especially the Linux formats as well as MSDOG. - - o Transparent FTP translator. - - o NFS client implementation. You should start with BSD's 4.4 code - and support the extensions they support; don't worry about Hurd - extensions right now. (The server we want to write ourselves - because it will probably involve changing the Hurd interfaces.) - - o A fancy terminal driver that uses readline and supports detach/attach. - --- -+1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David, -+1 617 253 8568 (W) -+- and Jonathan loved him as his own soul. -1105 Broadway | Then Jonathan made a covenant with David -Somerville, MA 02144 | because he loved him as his own soul. diff --git a/hurd-flash3 b/hurd-flash3 deleted file mode 100644 index 19a5f371..00000000 --- a/hurd-flash3 +++ /dev/null @@ -1,77 +0,0 @@ -Date: Tue, 05 Jul 1994 20:15:09 -0400 -From: mib@gnu.ai.mit.edu (Michael I Bushnell) -To: hurd-ann@gnu.ai.mit.edu -Subject: New Hurd snapshot - - -A new Hurd snapshot has been released. You can get it from -alpha.gnu.ai.mit.edu in the file /gnu/hurd-snap.tar.gz. You will need -the most recent version of the GNU C library; version 1.08.3 or later. -(Version 1.08.3 is an alpha release; you can get it from -alpha.gnu.ai.mit.edu in the same directory.) - -This snapshot of the Hurd has a limping terminal driver. It can run -emacs, bash, a whole slew of utilities, and (most importantly) GNU -Hello. - - -mib - - -Here is the new part of the NEWS file: - -The Hurd now runs all the programs in the GNU fileutils, textutils, -and shellutils distributions, with the exception of who. Most -importantly it runs GNU Hello. Also, emacs works (with the kludgy -`boot' terminal driver) and bash works. - -The simple pipes server works; it will be replaced eventually by the -pflocal server (which isn't done yet). The terminal driver is limping -but working. It doesn't support terminal ioctls yet. A minor bug in -auth has been fixed. boot interprets more Hurd protocols; this was -done to get emacs functioning. Some more-or-less serious bugs in exec -were fixed; they were found by running emacs (a quite large executable -indeed). At bootstrap time, init starts pipes and term itself; -eventually these will be passive translators, but we don't want to -write the new disk format until we're self-hosting or fsck and UX will -get confused. The file proc/primes.c has been documented; thanks go -to Jim Blandy. Some bugs in proc dealing with pgrp and wait were -fixed; a nasty hash table bug was also fixed. The simple shell can do -pipes. Several serious bugs in ufs were fixed dealing with extension -of large files and writes of data not aligned on block boundaries. -The ufs pager was over-serialized; that's been fixed. Directory -lookups and modifications now use mapped I/O directly; this is an -important speed-up. The structure of the pager lockes has been -changed significantly. UFS now supports Mach copying mode -MEMORY_OBJECT_COPY_DELAY; this significantly improves process startup -time. - -Some minor changes have been made to several interfaces. The -interface for fs.defs:dir_readdir has been totally changed. There are -some new fs.defs interfaces: file_check_access, file_notice_changes, -dir_notice_changes. The fsys.defs:fsys_getroot interface was changed -to work correctly. process.defs:proc_setprocargs is renamed, and a -fetch function proc_get_arg_locations is added. The ifsock.defs -interface was simplified. - -Several bugs were fixed in libdiskfs. The new dir_readdir interface -requires new support from format-specific code. Some race conditions -have been fixed. dir-pathtrans.c now deals correctly with multiple -slashes in a row. A new concept called "light references" allows -pagers to remain active without preventing truncate-on-nolinks from -working right. New interfaces in fs.defs are implemented (except -file_notice_changes). Active translator usage has been fixed to work -correctly, but passive translators are still untested. libdiskfs now -thinks it supports S_IFSOCK nodes, but that's untested (of course) -because pflocal isn't done yet. - -The passive translator startup interface in libfshelp has been -radically simplified. The pager library now lets other code set and -changee the attributes on objects, synchronously if desired. An -init/terminate race condition was fixed. The ports library now -allows single-threaded users to work right (they didn't before). The -trivfs library works; see the ifsock server for a simple example of -its use. See term or pipes for more complex examples. - -There is a task list in the file `tasks'; let me know if you are -interested in working on one of these. - diff --git a/hurd-flash4 b/hurd-flash4 deleted file mode 100644 index 89ae9848..00000000 --- a/hurd-flash4 +++ /dev/null @@ -1,101 +0,0 @@ -From: mib@gnu.ai.mit.edu (Michael I Bushnell) -To: hurd-ann@gnu.ai.mit.edu -Date: Mon, 8 Aug 94 16:01:23 -0400 -Subject: New Hurd Snapshot -X-Shopping-List: - (1) Starboard sauce (2) Cinematic lesions (3) Two-way alphabetic - accordions - - -A new Hurd snapshot has been placed on alpha.gnu.ai.mit.edu in -/pub/gnu/hurd-snap.tar.gz. - -It is expected that the next snapshot after this one will have signals -basically working and thus be usable for a self-hosting system. In -addition, the next snapshot will probably have the current state of -our networking code (which has been proceeding, but has been absent -from the snapshots). - -Here is the NEWS about this current snapshot, however. Because some -big changes were made to the makefile and directory structure, things -might have gotten inadvertently ommitted from the snapshot. If this -happened, please let me know ASAP and I'll fix it and make a new -snapshot. - - -mib - - -August 8, 1994: - -Structural changes: - -Makefiles have been vastly improved and are simpler. The programs -`su', `ps', and `sh' have been moved from separate dirs into `utils'; -the programs `symlink' and `ifsock' have been moved into `trans'. - -Several changes were made to GCC use. You should definitely get GCC -version 2.6.0 now. Version 2.6.1 will have distributed the proper -`specs' file for the i386-gnu target, but it isn't quite ready yet, so -you still have to copy hurd/gcc-specs into -gcc-lib/i386-gnu/2.6.0/specs. - - -Interface changes: - -The tioctl.defs suite is complete now. - -INTR RPC's have been changed; individual RPC's are no longer marked -INTR. Rather, entire interfaces are marked `INTR_INTERFACE' if they -conform to the library's signalling/interruption expectations. - -There is a new magical retry type (for dir_pathtrans and fsys_getroot) -called `machtype' and a new one `/'; the former is for @sys tweaks and -the latter cleans up the retry of root-based symlinks a bit. - -There is a new interface `login.defs'. - -The "dotdot node" is no longer passed at fsys_startup time; instead, -it is passed by fsys_getroot. - - -Library changes: - -The ports library now does death-timeouts for multi-threaded servers; -it doesn't actually work right yet, however. Also the ports library -has new features (soft vs. hard ports; no outstanding ports -notifications) that enable server-death to be done cleanly. (I hope; -libdiskfs and ufs haven't yet been changed to use it, so libports -might not actually have the right facilities yet.) - -The translator startup routines in libfshelp have been vastly improved -(so that they can actually be used). - -Numerous bugfixes in libdiskfs, particularly relating to translator -usage. Use new magical retry type `/' when appropriate. Use new -dotdot node protocol. O_FSYNC and O_NOATIME are now honored properly. -Alternative methods of storing symlinks are now supported through new -hooks. - -The new dotdot protocol is now used by libtrivfs. Also, users of the -library are now able to set the atime and mtime when necessary. - -The special threads version of malloc has been placed back in -libthreads now that the C library uses a Mach-safe version on its own. - - -Program changes: - -The `boot' program no longer implements the tioctl interface now that -the terminal driver works. - -A bug was fixed in the handling of pgrps in `proc'. - -Many bugfixes in term. The tioctl interface is now implemented. EOF -processing is fixed; break characters now work right. Signals and -interruption are now done correctly. VDISCARD works. - -Ufs has Some bigs fixed in dir.c. Filesystem upgraded to BSD 4.4. -There are now some compatibility flags. - -New program dev.trim does a very minimal /dev (but doesn't work yet). -New program dev is an initial (but poor) attempt at a real /dev. diff --git a/hurd-flash5 b/hurd-flash5 deleted file mode 100644 index 041a0ef7..00000000 --- a/hurd-flash5 +++ /dev/null @@ -1,23 +0,0 @@ -From: mib@gnu.ai.mit.edu (Michael I Bushnell) -Message-Id: <9409210619.AA17570@churchy.gnu.ai.mit.edu> -To: "Lots of potentially interested people and" -Subject: New milestone acheived by the GNU Hurd -X-Tom-Swiftie: "I can't get this fire started," Tom said woodenly. - - -I have just successfully compiled and run a null C program on the -Hurd. This is using GCC native as one would normally use GCC. - -Sadly, it took quite a while (too long, in fact) to read the large -archives that make up the GNU C library, but I think I know where the -substantial inefficiency is. - -Once that is done, I would be happy to label this a "self-hosting -system". But not just yet. - -The last bug preventing this was an error in dealing with files over -about 8 M; this came about because in order to link a program one -needed the GNU C library, which is over 9M when symbols are included. - - -mib - diff --git a/hurd-flash6 b/hurd-flash6 deleted file mode 100644 index e774714e..00000000 --- a/hurd-flash6 +++ /dev/null @@ -1,46 +0,0 @@ -Return-Path: -Received: from pdxgate.cs.pdx.edu by gnurd with uucp - (Linux Smail3.1.28.1 #14) id m0r66pm-00010fC; Fri, 11 Nov 94 17:00 PST -Received: from cs.pdx.edu by pdxgate.cs.pdx.edu (4.1/CATastrophe-9/19/94-U) - id AA05257; Fri, 11 Nov 94 16:40:48 PST -Received: from churchy.gnu.ai.mit.edu by cs.pdx.edu (4.1/CATastrophe-9/19/94-P) - id AA02600; Fri, 11 Nov 94 16:40:22 PST -Received: by churchy.gnu.ai.mit.edu (5.65/4.0) - id ; Fri, 11 Nov 94 16:45:35 -0500 -Received: by churchy.gnu.ai.mit.edu (5.65/4.0) - id ; Fri, 11 Nov 94 16:38:44 -0500 -Date: Fri, 11 Nov 94 16:38:44 -0500 -From: mib@gnu.ai.mit.edu (Michael I Bushnell) -Message-Id: <9411112138.AA12580@churchy.gnu.ai.mit.edu> -To: hurd-ann@gnu.ai.mit.edu, hurd-dev@gnu.ai.mit.edu, info-gnu@prep.ai.mit.edu -Subject: New Hurd Snapshot -X-Shopping-List: - (1) Horrendous collision devotions (2) Wondrous consolation (3) - Conscious cooking auctions -X-Filter: mailagent [version 3.0 PL19] for trent@gnurd.uu.pdx.edu - - -A new Hurd snapshot has been placed on alpha.gnu.ai.mit.edu. There -may be unforseen problems with this snapshot, so the old one has been -left. You may fetch this snapshot via anonymous FTP in the file -/gnu/hurd-snap.tar.gz. - -The Hurd requires a modified version of MiG; you can get it by -anonymous ftp to kahlua.cs.utah.edu in /pub/mach/mach4-UK02p6.tar.gz. -Note that we are not yet using Mach4 for the Hurd, but we plan to -switch as soon as its feasible. - -Other necessary software to run this snapshot include the latest -snapshot of binutils/ld/gas source from Cygnus and the latest GCC. -(Problems have been reported with GCC 2.6.1; you might want to wait -until 2.6.2 is released.) And, of course, you also need the latest -test version of the GNU C Library, found on alpha.gnu.ai.mit.edu. - -This is not yet a real release; it is certainly not up to the quality -of even a hesitant alpha release. But it may be useful for -educational value or to help with the Hurd effort. - -I will be out of town for most of the rest of the year; I will be -reading email but I may not be able to help with problems. Sorry... - - -mib diff --git a/hurd-flash7 b/hurd-flash7 deleted file mode 100644 index ce6e08d2..00000000 --- a/hurd-flash7 +++ /dev/null @@ -1,17 +0,0 @@ -Date: Wed, 12 Apr 1995 15:08:18 -0400 -From: Michael I Bushnell -To: hurd-ann@duality.gnu.ai.mit.edu -Subject: New Hurd Snapshot available - -A new hurd snapshot is now available from -ftp://alpha.gnu.ai.mit.edu/gnu/hurd-snap.tar.gz. - -This snapshot contains many improvements over the last one, and is -also probably easier to compile. - -This snapshot must be used with the most recent libc snapshot, -ftp://alpha.gnu.ai.mit.edu/gnu/libc-950411.tar.gz. Previous versions -of the library will not work right. - -If any files are discovered to be missing, please let me know asap. - diff --git a/hurd-flash8 b/hurd-flash8 deleted file mode 100644 index 555186ec..00000000 --- a/hurd-flash8 +++ /dev/null @@ -1,73 +0,0 @@ -Date: Sun, 23 Jul 1995 16:27:46 -0400 -Message-Id: <199507232027.QAA09306@geech.gnu.ai.mit.edu> -From: Michael I Bushnell -To: hurd-ann@gnu.ai.mit.edu -Subject: Hurd snapshot! -X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+ -+$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv -+ b+++ !D B-- e+ u++(*) h* f? r n y++ -X-Zippy-Says: I just had a NOSE JOB!! -Sender: owner-abshurd@cs.pdx.edu -Precedence: bulk - - -I have just put a new Hurd snapshot on alpha.gnu.ai.mit.edu in -/gnu/hurd-snap-950723.tar.gz. - -You will also need the new libc snapshot, which should appear in the -same place today. Older libc snapshots will not be happy. - -The binary images (hurd-floppy.fs.gz and hurd-image.tar.gz) have not -been updated. It is difficult to use the Hurd standalon, because the -Mach boot loaders can now no longer boot the Hurd. A new boot loader -is nearly finished. Perhaps we can make new binary images then, or a -volunteer might take over this useful work. (Hint, hint.) - -Michael - - - -Here is the NEWS: - -July 23, 1995 - -Shared libraries now work; use -static to link programs and avoid the -shared libraries. The Hurd programs are normally built static; this -will probably change soon. - -The ext2fs server now works, as do the tools to manipulate ext2fs -filesystems. A snapshot of the tools will be made soon under separate -cover. Many thanks to Ted Ts'o for his valuable work on the tools. - -Readers of the Makefiles will notice that we now generate dependencies -automatically. - -The old netserv library is gone. - -The `boot' hack has been modified slightly to avoid the normalq libc startup -files, because they no longer work with UX. - -Some small bugs have been fixed in the devio server. - -The ports library has been totally rewritten; new features permit -servers to have greater control over thread RPC's and port creation. - -The fshelp library now does most of the work for translator -interaction; it's simpler now too. Filesystems have much less work to -do; the relevant code in libdiskfs is now understanble instead of -unparseable chaos. - -The ports library provides for timeouts; the diskfs library almost -uses it, but because of a bug, it's disabled for now. - -Filesystems are now expected to sync themselves if necessary; the new -fsys_set_options RPC provides for changeing (or cancelling) the sync -intervale. The diskfs library does this for you. The update program -is no longer necessary. - -A small bug in the proc server has been hacked around; the real fix -will come later. - -Many important bugs in the C library have been fixed since the last -snapshot; perhaps all of them. ;-) - diff --git a/hurd-flash9 b/hurd-flash9 deleted file mode 100644 index 1ff32ba9..00000000 --- a/hurd-flash9 +++ /dev/null @@ -1,39 +0,0 @@ -Date: Wed, 29 Nov 1995 13:13:23 -0500 -Message-Id: <199511291813.NAA10983@duality.gnu.ai.mit.edu> -From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) -To: hurd-ann@gnu.ai.mit.edu (and others) -Subject: Announcement -X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+ -+$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv -+ b+++ !D B-- e+ u++(*) h* f? r n y++ -X-Windows: The Cutting Edge of Obsolescence. -Sender: owner-abshurd@cs.pdx.edu -Precedence: bulk - - -The Hurd has succesfully completed its first FTP: - -bash# ftp 128.52.46.31 -Connected to 128.52.46.31. -220 albert.gnu.ai.mit.edu FTP server (Version 5.60) ready. -Name (128.52.46.31:root): -331 Password required for root. -Password:230 User root logged in. -ftp> cd ~mib -250 CWD command successful. -ftp> get ftptest -200 PORT command successful. -150 Opening ASCII mode data connection for ftptest (16 bytes). -226 Transfer complete. -17 bytes received in 0.07 secs (0.24 Kbytes/sec) -ftp> quit -221 Goodbye. -bash# cat ftptest -this is a test. -bash# - - -Tre cool. - -Michael - diff --git a/hurd/history.mdwn b/hurd/history.mdwn index 7ee5df5a..e749136f 100644 --- a/hurd/history.mdwn +++ b/hurd/history.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 1998, 1999, 2001, 2002, 2007, 2008 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 @@ -8,5 +9,79 @@ 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]]."]]"""]] -History 1997-2003 -
Personal view of Marcus Brinkmann about Hurd development in 1997-2003. +Richard Stallman (RMS) started GNU in 1983, as a project to create a +complete free operating system. In the text of the GNU Manifesto, he +mentioned that there is a primitive kernel. In the first GNUsletter, +Feb. 1986, he says that GNU's kernel is TRIX, which was developed at +the Massachusetts Institute of Technology. + +By December of 1986, the Free Software Foundation (FSF) had "started +working on the changes needed to TRIX" [Gnusletter, Jan. 1987]. +Shortly thereafter, the FSF began "negotiating with Professor Rashid +of Carnegie-Mellon University about working with them on the +development of the Mach kernel" [Gnusletter, June, 1987]. The text +implies that the FSF wanted to use someone else's work, rather than +have to fix TRIX. + +In [Gnusletter, Feb. 1988], RMS was talking about taking Mach and +putting the Berkeley Sprite filesystem on top of it, "after the parts +of Berkeley Unix... have been replaced." + +Six months later, the FSF is saying that "if we can't get Mach, we'll +use TRIX or Berkeley's Sprite." Here, they present Sprite as a +full-kernel option, rather than just a filesystem. + +In January, 1990, they say "we aren't doing any kernel work. It does +not make sense for us to start a kernel project now, when we still +hope to use Mach" [Gnusletter, Jan. 1990]. Nothing significant occurs +until 1991, when a more detailed plan is announced: + +
+We are still interested in a multi-process kernel running on top of +Mach. The CMU lawyers are currently deciding if they can release Mach +with distribution conditions that will enable us to distribute it. If +they decide to do so, then we will probably start work. CMU has +available under the same terms as Mach a single-server partial Unix +emulator named Poe; it is rather slow and provides minimal +functionality. We would probably begin by extending Poe to provide +full functionality. Later we hope to have a modular emulator divided +into multiple processes. [Gnusletter, Jan. 1991]. +
+ +RMS explains the relationship between the [[documentation/Hurd_and_Linux]], where he mentions +that the FSF started developing the Hurd in 1990. As of [Gnusletter, +Nov. 1991], the Hurd (running on Mach) is GNU's official kernel. + +--- + +# Announcements + +These are all the announcements made over the years. Most of them were +either sent to the gnu.announce news group or Hurd interest +mailing lists. + + * [[hurd-flash15]] -- Release 0.2 announcement (complete GNU system) + * [[hurd-flash14]] -- Release 0.2 announcement (Hurd) + * [[hurd-flash13]] -- Test release announcement (Aug 96) + * [[hurd-flash12]] -- Test release status (Jul 96) + * [[hurd-flash11]] -- Binary image available, Apr 96 + This and [NetBSD](http://www.netbsd.org/) boot flopies should be enough to + get a working GNU/Hurd system! + * [[hurd-flash10]] -- New Snapshot, Apr 96 -- NFS and lots else works! + * [[hurd-flash9]] -- News Flash, Nov 95 -- ftp works! + * [[hurd-flash8]] -- New Snapshot, Jul 95 -- ext2fs support + * [[hurd-flash7]] -- New Snapshot, Apr 95 + * [[hurd-flash6]] -- News flash, Nov 94 + * [[hurd-flash5]] -- News flash, Sep 94 -- gcc runs! + * [[hurd-flash4]] -- News flash, Aug 94 + * [[hurd-flash3]] -- News flash, Jul 94 -- emacs runs! + * [[hurd-flash2]] -- News flash, May 94 + * [[hurd-flash]] -- News flash, Apr 94 -- it boots! + * [[hurd-announce2]] -- GNU Hurd announcement, Nov 93 + * [[hurd-announce]] -- GNU Hurd announcement, May 91 + +--- + + * [History + 1997-2003](http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00718.html) + -- personal view of Marcus Brinkmann about Hurd development in 1997-2003. diff --git a/hurd/history/hurd-announce b/hurd/history/hurd-announce new file mode 100644 index 00000000..2f165ad8 --- /dev/null +++ b/hurd/history/hurd-announce @@ -0,0 +1,47 @@ +From mib@PREP.AI.MIT.EDU Tue May 7 12:07:53 1991 +From: mib@PREP.AI.MIT.EDU +Newsgroups: gnu.announce +Subject: FSF work on a GNU OS +Date: 6 May 91 22:15:22 GMT +Reply-To: mib@prep.ai.mit.edu +Distribution: gnu +Organization: GNUs Not Usenet + +The Free Software Foundation is beginning work on a GNU operating +system built on top of the Mach 3.0 microkernel. There are three +goals to this project worth noting: + +o Binary compatability with 4.4 BSD, and other U*x or U*xish systems + on other hardware where appropriate, convenient, and consistent with + the design; + +o Posix compliance (in combination with the GNU C Library and the GNU + C Compiler); and + +o Ease of use as well as several new features and functionality. + + +I am interested in constructive criticism on the interfaces, design, +and implementation from experts in the field of OS research and design +consistent with the above goals. Advice from seasoned U*x hackers is +especially welcome. + +We have a mailing list for discussion. Currently there is little +discussion on the group; the major contributors to the ideas behind +the design all live in the Boston area at this point, and work has +been done via face-to-face communication. I would like to open the +field of discussion to a broader base, both to get wider dissemination +of the ideas behind the current design, as well as to get a greater +breadth of criticism. Periodic postings are currently made to the +mailing list containing a snapshot of the interfaces used by the +various pieces of the system. I would like to see discussion as well; +perhaps we need a critical mass to get this. + +Interested individuals should send me email. I don't regularly read +the newsgroups to which this message is posted. + + +[U*x is an abbreviation for a well-known trademark of AT&T. :-)] + + -mib + diff --git a/hurd/history/hurd-announce2 b/hurd/history/hurd-announce2 new file mode 100644 index 00000000..dce41c43 --- /dev/null +++ b/hurd/history/hurd-announce2 @@ -0,0 +1,143 @@ +From mib@gnu.ai.mit.edu Wed Nov 3 21:51:03 1993 +Path: usenet.ee.pdx.edu!cs.uoregon.edu!ogicse!emory!nigel.msen.com!sdd.hp.com!swrinde!cs.utexas.edu!uunet!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!prep.ai.mit.edu!gnulists +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +Newsgroups: gnu.announce,gnu.misc.discuss +Subject: Hurd status and call for volunteers +Message-ID: <9311020719.AA02206@geech.gnu.ai.mit.edu> +Date: 1 Nov 93 21:19:05 GMT +Article-I.D.: geech.9311020719.AA02206 +Followup-To: gnu.misc.discuss +Distribution: world +Lines: 124 +Approved: info-gnu@prep.ai.mit.edu +To: info-gnu@prep.ai.mit.edu +X-Shopping-List: + (1) Chaotic casino griddles (2) Cervical congestion (3) Neoclassical + consoles +Xref: usenet.ee.pdx.edu gnu.announce:160 gnu.misc.discuss:3985 + +This message to help sate curiosity, as well as to ask for volunteers. +Until we are ready for alpha test, this is the last such message that +will be posted here. If you want to receive further such messages, +send mail to hurd-ann-request@gnu.ai.mit.edu and ask to be put on that +(moderated) announcements list. + + +What is already done with the Hurd: + +The filesystem is complete; it runs (read-only), and most of its calls +have been tested and work. The filesystem is able to download +programs, by a kludge similar to the kludge used to enable the kernel +to download the first task. In the actual bootstap sequence, it will +download the execserver. + +The proc and auth servers are completed; the exec server is nearly +complete (for a.out, not for bfd). + +C library support for Mach and Hurd rpc stubs, and some of the mach +and hurd specific code, is done. Much untested and probably wrong +code has been written to implement Unix "system calls". A large piece +of this (the descriptor management code) is believed by Roland to have +some architectural flaw, but he isn't sure. + +Some small filesystem servers (shadow directories, for example) have +been written, but have not been compiled, let alone tested. + + +There are currently three things happening wrt the Hurd: + +I am spending nearly all my time getting things to boot and run. My +work is currently directed toward that goal; in the immediate present +I am working with Roland on getting the library in its near-final +state (which will last a long time) to make compiling easier. It is +because this is nearly done that I can send this message. + +Roland is working on the library. Most of the remaining architectural +work is done and being tested. Then Roland will work on integrating +cthreads (which is mostly busywork), miscellaneous filesystem calls, +and then file descriptors. After that comes signals. + +Jan Brittenson will be working on the network server library. This is +a library that, when linked against a BSD protocol stack, will produce +a Hurd network server. (Such a server implements the socket interface +in socket.defs.) + + +There are four general tasks that can be done by other people: + +1. Completing the existing work on the terminal driver. The existing +work implements most of the logic you already associate with a Posixy +terminal driver; it needs the port management and buffering logic +added. + +2. Writing a readline terminal driver. We will want, as an +alternative to the Posixy terminal driver, a readline type terminal +driver. + +3. Writing miscellaneous shell utilities. Here we need shell +utilities to create translators, etc. They should have a nice rich +set of features to do all kinds of GNU things. + +4. Writing miscellaneous filesystem servers. Here we need a +transparent tar server, a transparent FTP server, and the like. + + +Future plans for work to be written by me (once the bootstrap works, +and in addition to testing library code as Roland finishes it): + +o split the existing filesystem into three parts: + o a library for port management for complicated multi-threaded + servers; + o a library for "normal" disk-based filesystems; + o ufs specific code. + +o Write the PF_FILE socket server (what you know as PF_UNIX). + +o Finish the posixy terminal driver if nobody else has. + +o Write miscellaneous shell utilities that nobody else has. + +o Build a self-hosting system. + + +What you need in order to be able to help now: + +o A 386 PC running Mach 3.0. If you have some other kind of hardware, + then you need to port the GNU C library support first. I'm not + entirely sure how much work that involves; you will need to contact + Roland. It might be too much trouble at this point to spend any + effort on it. It's best if it's a machine for which a free port of + Mach is available, though you could do useful work even if it's not. + + If you are not currently running Mach 3.0 with somebody's + single-server, then it is very unlikely you could help, unless you + have a Unix source license. In that case, you could talk to CMU + (write mach@cs.cmu.edu) to find out how to get Mach 3.0 running on + your machine. It is not possible to do development without a Unix + emulator of some kind; just bare Mach 3.0 is not sufficient. I have + neither the time nor knowledge to help someone get a 3.0 + single-server system running. + +o Clue. I don't have enough time to explain operating systems or Unix + to people. You need to have an iron-clad grasp of Unix semantics + (specificaly BSD); it's essential that things be exactly right from + that standpoint. It's not enough that you've programmed Unix + before; you need to understand all the nits. However, you may + disregard my previous comments about a "two question limit". You do + need the ability to intuit to some extent, however. + +o Time. It's not good for me to delegate a task and then have nothing + happen on it. If you have a full-time job where you can't justify + Hurd work as part of your job, you might find that you don't really + have as much time as you thought. Please make sure you really have + enough time before volunteering for a task. + +o Efficient net access. Without a real Internet connection (mail only + is not sufficient), it will be impossible for you to do development + right now. + + +If you think you can help, send me email. If you don't think you can +help right now, then don't give up: the list of conditions will change +as the list of delegatable tasks changes. + diff --git a/hurd/history/hurd-flash b/hurd/history/hurd-flash new file mode 100644 index 00000000..d1bacc79 --- /dev/null +++ b/hurd/history/hurd-flash @@ -0,0 +1,22 @@ +Path: gnurd!usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!swrinde!gatech!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mib +From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell) +Newsgroups: gnu.misc.discuss,comp.os.mach +Subject: Hurd now bootstraps +Date: 05 Apr 1994 21:49:50 GMT +Organization: Free Software Foundation, Cambridge, MA +Lines: 11 +Message-ID: +NNTP-Posting-Host: churchy.gnu.ai.mit.edu + + +The GNU Hurd now bootstraps, successfully starting the core servers +(the filesystem, exec server, process server, auth server, and init) +and running the first program. A snapshot of the code that did this +is on alpha.gnu.ai.mit.edu in the usual place, /gnu/hurd-snap.tar.gz. + +-- ++1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David, ++1 617 253 8568 (W) -+- and Jonathan loved him as his own soul. +1105 Broadway | Then Jonathan made a covenant with David +Somerville, MA 02144 | because he loved him as his own soul. + diff --git a/hurd/history/hurd-flash10 b/hurd/history/hurd-flash10 new file mode 100644 index 00000000..d6d5685b --- /dev/null +++ b/hurd/history/hurd-flash10 @@ -0,0 +1,25 @@ +Date: Mon, 15 Apr 1996 15:28:29 -0400 +Message-Id: <199604151928.PAA00636@geech.gnu.ai.mit.edu> +From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +To: hurd-ann@gnu.ai.mit.edu +Subject: New Hurd snapshot available +X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+ ++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv ++ b+++ !D B-- e+ u++(*) h* f? r n y++ +X-Tom-Swiftie: "Use the `&' operator to get the address," Tom pointed out. +Sender: owner-abshurd@cs.pdx.edu +Precedence: bulk + + +I have just cut a new source snapshot. If things go nicely, a binary +snapshot may appear soon as well. You can find this snapshot as + +ftp://alpha.gnu.ai.mit.edu/gnu/hurd-snap-960415.tar.gz + +Many many things work! Emacs built native and just *went*. The +system now works standalone; you can use gdb (it's much nicer than +other mach-ish gdb's, of course); the network is functional (complete +with NFS), etc. + +Michael + diff --git a/hurd/history/hurd-flash11 b/hurd/history/hurd-flash11 new file mode 100644 index 00000000..57851b01 --- /dev/null +++ b/hurd/history/hurd-flash11 @@ -0,0 +1,25 @@ +From: Miles Bader +To: hurd-ann@gnu.ai.mit.edu +Date: Thu, 18 Apr 1996 19:08:07 -0400 +Subject: hurd binary image + + +A filesystem image from a working hurd system, corresponding to the latest +snapshot, is available as: + + ftp://alpha.gnu.ai.mit.edu/gnu/hurd-image-960418.tar.gz + +The whole tree takes about 37meg (warning -- it unpacks into `.'). Follow +the instructions in ./INSTALL-binary to make a working hurd system. + +Due to a timely trashing of the disk on our main hurd machine, it has been +verified that it is possible to make a bootable hurd system from scratch +using this image and a set of netbsd 1.1 boot floppies... + +The sources for the mach kernel included in the image are available in the +same directory as mach4-UK22.tar.gz and mach4-i386-UK22.tar.gz. + +-Miles +-- +Miles Bader / miles@gnu.ai.mit.edu / (617) 253-8568 +Amadera e ike! diff --git a/hurd/history/hurd-flash12 b/hurd/history/hurd-flash12 new file mode 100644 index 00000000..5be9c94e --- /dev/null +++ b/hurd/history/hurd-flash12 @@ -0,0 +1,76 @@ +From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +Newsgroups: gnu.misc.discuss +Subject: Hurd 0.0 release status +Followup-To: gnu.misc.discuss +Date: 13 Jul 1996 23:53:41 GMT +Organization: Touring Consulting Services +Lines: 35 +Message-ID: +NNTP-Posting-Host: churchy.gnu.ai.mit.edu + + +People are eager to know how close we are to release, so here's an +update: + +There is one rather annoying bug I'd like to find which is causing +random crashes. I expect this will not be too hard to locate. There +are some more trivial bugs, but the release will not be held up for +them. + +Forty-three packages of GNU software have been built native. +Remaining to be built are three packages for which new releases are +expected soon. + +Also remaining to be built native are bash, gdb, mach, the Hurd +itself, and the internet utilities and daemons. We intend to sync our +separate copy of libc source with the libc maintainer, and then build +it native too. + +Because of obnoxious export restrictions, we have still to make +separate shared libraries for the crypt functions. + +Except for the actual final packaging, all the release engineering +tasks to be done have been completed. + + +To summarize, we still need to: + +o Fix one obnoxious bug +o Compile three packages that are waiting for release; +o Compile gdb, bash, mach, and hurd native +o Sync libc source and compile native +o Deal with crypt shared libraries +o Final packaging + +Michael + +From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +Newsgroups: gnu.misc.discuss +Subject: Re: Hurd--ne plus ultra of vaporware? +Date: 17 Jul 1996 03:02:14 GMT + +In article <4sg6tp$n4t@linux.cs.Helsinki.FI> torvalds@linux.cs.Helsinki.FI (Linus Torvalds) writes: + + Hey! We could also ask some well-known rock-group for one of their + lyrics, and use that as the theme song for the Hurd release. And then + we could ask shops to stay open longer to sell the Hurd! Whaddaya think? + Don't say it has been delayed, just shout so loudly about all the new + features that nobody cares about the delay? + +Perhaps we could get Morrisey to sing the song. He's very good +looking. Much better looking than that Mick Jagger fellow. + +Or something delicate, like Bach's French Suite in G. That would be +fun. + +In any case, here's the state of the release: + +o Everything but nine packages has been compiled native. +o The random crash bug I alluded to is fixed. +o We have to build a floppy image for part of the installation instructions. + +That's it. I bet you nobody in Redmond has ever made a statement like +that... + +Michael + diff --git a/hurd/history/hurd-flash13 b/hurd/history/hurd-flash13 new file mode 100644 index 00000000..a2de6bfd --- /dev/null +++ b/hurd/history/hurd-flash13 @@ -0,0 +1,120 @@ +Date: Mon, 5 Aug 1996 22:36:31 -0400 +From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) +To: info-gnu@prep.ai.mit.edu, hurd-ann@gnu.ai.mit.edu, hurd-dev@gnu.ai.mit.edu +Subject: Hurd 0.0 and GNU 0.0 released +X-Name-Change: My name used to be `Michael'; now it is `Thomas'. +X-Tom-Swiftie: "I guess I shouldn't have broken the mirror," Tom reflected. + + + + +I am pleased to announce version 0.0 of the GNU Hurd, available via +anonymous FTP from prep.ai.mit.edu [18.159.0.42] in the file +/pub/gnu/hurd-0.0.tar.gz (about 1.2 MB compressed). + +This file contains complete source code for the following: + +Hurd servers: + + auth, crash, devio, devport, exec, ext2fs, fifo, fwd, ifsock, init, + magic, new-fifo, nfs, null, pfinet, pflocal, proc, symlink, term, + ufs. + +Hurd libraries: + + diskfs, fshelp, ihash, iohelp, netfs, pager, pipe, ports, ps, + shouldbeinlibc, store, threads, trivfs. + +Hurd utilities and other programs: + + boot, shd, ps, settrans, showtrans, sync, su, mount, fsysopts, + storeinfo, login, w, uptime, hurdids, loginpr, sush, vmstat, + portinfo, devprobe, reboot, halt, fsck, fsck.ufs, mkfs.ufs, clri.ufs, + stati.ufs, getty, rc. + + +------ + + +In addition, we have prepared a binary distribution of a complete +version 0.0 GNU system corresponding to this Hurd release. This +release runs only on PC-AT compatible systems with i[345]86 +processors. + +The GNU Hurd, plus Mach, is a kernel, not an operating system. The +GNU operating system, like the Unix operating system, consists of many +components, including kernel, libraries, compilers, assembler, shell, +parser generators, utilities, window system, editors, text formatters, +and so on. The GNU project set out a decade ago to develop this +system, and we've been writing various components of it ever since. + +This release uses the `UK22' version of the Mach kernel, as +distributed by the University of Utah. It is too difficult to prepare +a detailed list of supported devices at this point. Common disk +controllers and ethernet cards are generally supported. + +This release does not contain the X Window System. + +This release may be fetched by anonymous FTP from prep.ai.mit.edu +[18.159.42] in the directory /pub/gnu/gnu-0.0/. + +In that directory, you should find the following files: + + README + SOURCES + INSTALL-binary + grub-boot.image (about 1.4 MB, not compressed) + gnu-0.0.tar.gz (about 56.9 MB compressed) + gnu-0.0-stripped.tar.gz (about 26.2 MB compressed) + +SOURCES contains a complete list describing the sources for the +binaries found in the image. INSTALL-binary contains complete +installation instructions for this release. + +(The files README, SOURCES, and INSTALL-binary are also found in the +root directory of the gnu-0.0 release.) + +gnu-0.0.tar.gz holds the image of the complete system. It unpacks +into a directory that requires approximately 233 MB of disk space. + +gnu-0.0-stripped.tar.gz holds the same contents as gnu-0.0, except +that executable programs have been stripped to save space, and the +libraries have had debugging symbols stripped to save space and speed +linking. It unpacks into a directory that requires about 85.5 MB of +disk space. + +We recommend using the unstripped image, or you will be unable to +debug anything. Surely there are bugs. So fetch the unstripped +image, at least to have around. + +grub-boot.image is an image of a 3.5" floppy disk that you will need +in order to complete part of the installation instructions. + +The following free software packages are found in this release: + + autoconf, automake, bash, bc, binutils, bison, cpio, cvs, diffutils, + doschk, e2fsprogs, ed, emacs, fileutils, findutils, flex, from, gawk, + gcal, gcc, gdb, gdbm, gettext, glibc, gmp, gperf, grep, grub, gzip, + hello, hurd, indent, inetutils, less, mach, make, m4, miscfiles, + ncurses, nethack, nvi, patch, ptx, rcs, readline, recode, sed, + serverboot, sharutils, shellutils, tar, termcap, termutils, texinfo, + textutils, time, wdiff. + + +------ + + +Here are md5sum checksums for the files mentioned in this message: + +b5f888bab3eb193fe97a00a141324c9d INSTALL-binary +345dcd826747d7b11fc78f4db162d75b README +1a5744bb4ed3448045fa6d24153d65fe SOURCES +f7b1bc428bc4ee29977a5b28f5762092 gnu-0.0-stripped.tar.gz +24554c58e5c89f295176e17d21dbae8e gnu-0.0.tar.gz +8338c619d860b71bc4128c9c0fd39d63 grub-boot.image +1fd18ccc4c81d051b83d28b13dc07ee2 hurd-0.0.tar.gz + +----- + +Br. Thomas Bushnell, n/BSG + diff --git a/hurd/history/hurd-flash14 b/hurd/history/hurd-flash14 new file mode 100644 index 00000000..2d67687a --- /dev/null +++ b/hurd/history/hurd-flash14 @@ -0,0 +1,62 @@ +I am pleased to announce version 0.2 of the GNU Hurd, available via +anonymous FTP from prep.ai.mit.edu [18.159.0.42] in the file +/pub/gnu/hurd-0.2.tar.gz (about 1.37 MB compressed). + +(The GNU Hurd, plus Mach, is a kernel, not an operating system. The +GNU operating system, like the Unix operating system, consists of many +components, including kernel, libraries, compilers, assembler, shell, +parser generators, utilities, window system, editors, text formatters, +and so on. The GNU project set out a decade ago to develop this +system, and we've been writing various components of it ever since.) + +This release contains many bug fixes from version 0.1. Many thanks to +all the people who are helping find bugs! + +The best way you can help find bugs is to try and compile and use on +the Hurd as many programs as you can find and find out where bugs +still exist. There are also unimplemented features, and your reports +will help us to prioritize which things we work on. + +The system is vastly more reliable than it has been in the past. + +One important addition: + + New programs addauth, rmauth, unsu, su, and setauth modify the uid + sets of running programs. Using addauth you can add root to your + emacs, write a file, and then use rmauth to take the uid back. (Of + course, passwords are required when necessary.) New program `ids' + will tell you what all the user ids are that a program has. Note + that in the Hurd a program can have several user ids all at once, + just like Unix supports having several group ids. Now that you can + dynamically change the ids of running programs, system + administration (among other things) becomes much easier. + +For more detailed news, see the NEWS file in the distribution. + +This release contains complete source code for the following: + +Hurd servers: + + auth, crash, devport, exec, ext2fs, fifo, fwd, ifsock, init, + magic, new-fifo, nfs, null, pfinet, pflocal, proc, symlink, term, + ufs, storeio, firmlink. + +Hurd libraries: + + diskfs, fshelp, ihash, iohelp, netfs, pager, pipe, ports, ps, + shouldbeinlibc, store, threads, trivfs, hurdbugaddr, ftpconn + +Hurd utilities and other programs: + + boot, shd, ps, settrans, showtrans, sync, su, mount, fsysopts, + storeinfo, login, w, uptime, ids, sush, vmstat, portinfo, devprobe, + reboot, halt, fsck, fsck.ufs, mkfs.ufs, clri.ufs, stati.ufs, getty, + rc, e2os, vminfo, nfsd, mail.local, serverboot, MAKEDEV, loginpr, + addauth, rmauth, unsu, setauth, ftpcp, ftpdir. + +We are also making a complete GNU 0.2 binary release, which will +include Hurd 0.2, glibc 2.0.4, gnumach 1.1.2, and many other +programs. This binary release is announced separately. + + +Thomas Bushnell, n/BSG diff --git a/hurd/history/hurd-flash15 b/hurd/history/hurd-flash15 new file mode 100644 index 00000000..0785ac59 --- /dev/null +++ b/hurd/history/hurd-flash15 @@ -0,0 +1,60 @@ + +I am pleased to announce version 0.2 of the complete Hurd based GNU +system. This release runs only on PC-AT compatible systems with +i[3456]86 processors. + +The GNU Hurd, plus Mach, is a kernel, not an operating system. The +GNU operating system, like the Unix operating system, consists of many +components, including kernel, libraries, compilers, assembler, shell, +parser generators, utilities, window system, editors, text formatters, +and so on. The GNU project set out a decade ago to develop this +system, and we've been writing various components of it ever since. + +This release uses the GNUmach distribution of the Mach kernel, version +1.1.3. Popular PC devices are generally supported. + +This release does not contain the X Window System. + +This release may be fetched from the directory +ftp://prep.ai.mit.edu/pub/gnu/gnu-0.2. (prep.ai.mit.edu is 18.159.42, +for the nameserver-impaired). + +In that directory, you should find the following files: + +README +SOURCES +INSTALL-binary +grub-boot.image (about 1.5 MB, not compressed) +gnu-0.2.tar.gz (about 73 MB compressed) + +SOURCES contains a complete list describing the sources for the +binaries found in the image. INSTALL-binary contains complete +installation instructions for this release. + +(The files README, SOURCES, and INSTALL-binary are also found in the +root directory of the gnu-0.2 release.) + +gnu-0.2.tar.gz holds the image of the complete system. It unpacks +into a directory that requires approximately 285 MB of disk space. + +grub-boot.image is an image of a 3.5" floppy disk that you will need +in order to complete part of the installation instructions. + +The following free software packages are included in this release: + +autoconf automake bash bc binutils bison cpio cvs diffutils doschk +e2fsprogs ed emacs emacs lisp manual fileutils findutils flex from g77 +gawk gcal gcc gdb gettext glibc gmp gnuchess gnumach gnugo grep grub +gzip hello hurd indent inetutils less libg++ lynx m4 make miscfiles +ncurses nethack nvi patch perl ptx readline rcs recode sed sendmail +sh-utils sharutils tar termutils texinfo textutils time wdiff + +-- + +Here are md5sum checksums for the files mentioned in this message: + +3749b016ab581e007b90d17b9092e134 INSTALL-binary +1f800c326ba4c3a0b3f3a3463597317b README +40d1e1a38dd86f28fe2718081ac865cb SOURCES +f29c1a03c1667a8019b66f6effa89d39 gnu-0.2.tar.gz +8ad3c7254802a16068a956e836266212 grub-boot.image diff --git a/hurd/history/hurd-flash2 b/hurd/history/hurd-flash2 new file mode 100644 index 00000000..b1d4f66f --- /dev/null +++ b/hurd/history/hurd-flash2 @@ -0,0 +1,152 @@ +From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell) +Newsgroups: gnu.misc.discuss,comp.os.mach,comp.os.linux.development,comp.os.linux.misc,comp.unix.pc-clone.32bit +Subject: GNU Hurd Task List and Call for Volunteers +Followup-To: gnu.misc.discuss +Date: 18 May 1994 17:54:47 GMT +Organization: FOO +Lines: 140 +Message-ID: +NNTP-Posting-Host: churchy.gnu.ai.mit.edu +Xref: usenet.ee.pdx.edu gnu.misc.discuss:7630 comp.os.mach:1434 comp.os.linux.d +evelopment:9867 comp.os.linux.misc:16767 comp.unix.pc-clone.32bit:5854 + + +Now that the Hurd can run (albeit haltingly) on its own, it is +possible for people who do not have Mach 3.0 single-servers to +contribute without much trouble. (However, if you don't have a +single-server, you probably won't be able to use a debugger, but that +doesn't mean you can't do debugging, right?) + +We at the FSF don't have any expertise in setting up Mach 3.0 +machines; the machines that we do development on belong to the Open +Software Foundation and were set up by them. So one of the things on +the task list is to organize things so that people (like us and most +of you) who don't know how to do it can do it. It's not impossible to +figure out, it's just a pain and a marvelous thing for a volunteer to +do. + +You can get Mach 3.0 from CMU; you get the C library and the Hurd from +us. You need the soon-to-be-released version 1.07.6 of the C library +and the latest Hurd snapshot (as well as our special version of MiG) +from alpha.gnu.ai.mit.edu. + +All our work is based upon i386. The Hurd (except for a few programs; +see the Hurd README file) is machine independent. The C library +should not be too much trouble to port. Ports and information about +porting difficulty for either of these are greatly desired. + +The Hurd is not yet self-hosting. While you are welcome to fetch the +code and put things together, it is not likely that you will have a +useful system right now. But you might be able to do significant work +(see the task list below). And, even if you can't do significant +work, I'm interested in hearing about any places where you had +particular difficulty. + +If you want to start on one of these tasks, please let me know so I +can keep track of volunteers properly. This task list will be updated +periodically; gnu@prep.ai.mit.edu always has the latest version. + + -mib + +GNU Hurd Task List Version 1.0. + +If you would like to work on one of these, please contact mib@gnu.ai.mit.edu. + + +Mach 3.0 Work + + o Mach 3.0 comes with CMU makefiles that depend on a drecky environment. + It would be very helpful to have makefiles and installation stuff so + that it worked well for cross-compilation between systems and used + GNU tools. + + o MiG needs to be made able to support cross-compilation. + + o A replacement for MiG that understood C .h files. + + o Bootstrap tools and documentation to help people set up Mach 3.0 + machines if they already have Linux; if they already have Net BSD; + if they don't have anything. + + o Mach 3.0 needs to provide support for task virtual timers similar + in functionality to the Unix ITIMER_PROF and ITIMER_VIRTUAL timers. + + o Mach 3.0 needs to provide a way for users to do statistical PC + profiling similar to the Unix profil system call. + + o Mach 3.0 needs a facility to automatically send task and thread + status on task/thread exit to a port that can only be changed by + a privileged user; this would be used to implement process + accounting. + + o Mach 3.0 needs a facility to find out what task is the parent of + a given task. + + o Mach 3.0 needs a facility to find out which pages of a task's + address space are in core to implement Unix's mincore call. + + o Mach 3.0 needs a facility to do msync. + + o Mach 3.0 needs a replacement for MEMORY_OBJECT_COPY_CALL that + works at least for the cases needed in ordinary files. (Write mib if + you want to know what the problem is and some ideas about how to + solve it.) + + o Mach 3.0 needs proxy memory objects. (mib can tell you what these + are and why they are important.) + + o Mach 3.0 needs a way to do per-task resource counters that are + accessible to servers called by the task. + + o Mach 3.0 needs facilities to implement resource limits of various sorts. + + o Mach 3.0 needs a way to have a thread's CPU time statistics + include time spent by servers on its behalf. + + o Of course, free ports are always necessary to machines that don't + already have free ports. + + o Much work can be done doing research in how to improve Mach VM + performance and timesharing scheduling policy. + + +Hurd work (these are brief descriptions; mib can give more information): + + o We need a translator for /dev. + + o We need a replacement for utmp and wtmp that understands the + Hurd `login collection' concept. Programs like who and finger + then need to be changed to use this. + + o We need some existing shell programs changed to do Hurd things: + like ls, su, fsck, tar, cpio, etc. + + o Some new programs need to be written: login, getty, ps, tools + for new filesystem features. + + o Shadow directory translators. (Roland has the beginnings of this.) + + o A system for write, send, talkd and so forth to bleep users; + this should be integrated with the utmp replacement above. + + o X. + + o A filesystem for /tmp that uses virtual memory instead of disk. + + o Filesystem implementations (using libdiskfs) for other popular + formats, especially the Linux formats as well as MSDOG. + + o Transparent FTP translator. + + o NFS client implementation. You should start with BSD's 4.4 code + and support the extensions they support; don't worry about Hurd + extensions right now. (The server we want to write ourselves + because it will probably involve changing the Hurd interfaces.) + + o A fancy terminal driver that uses readline and supports detach/attach. + +-- ++1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David, ++1 617 253 8568 (W) -+- and Jonathan loved him as his own soul. +1105 Broadway | Then Jonathan made a covenant with David +Somerville, MA 02144 | because he loved him as his own soul. diff --git a/hurd/history/hurd-flash3 b/hurd/history/hurd-flash3 new file mode 100644 index 00000000..19a5f371 --- /dev/null +++ b/hurd/history/hurd-flash3 @@ -0,0 +1,77 @@ +Date: Tue, 05 Jul 1994 20:15:09 -0400 +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +To: hurd-ann@gnu.ai.mit.edu +Subject: New Hurd snapshot + + +A new Hurd snapshot has been released. You can get it from +alpha.gnu.ai.mit.edu in the file /gnu/hurd-snap.tar.gz. You will need +the most recent version of the GNU C library; version 1.08.3 or later. +(Version 1.08.3 is an alpha release; you can get it from +alpha.gnu.ai.mit.edu in the same directory.) + +This snapshot of the Hurd has a limping terminal driver. It can run +emacs, bash, a whole slew of utilities, and (most importantly) GNU +Hello. + + -mib + + +Here is the new part of the NEWS file: + +The Hurd now runs all the programs in the GNU fileutils, textutils, +and shellutils distributions, with the exception of who. Most +importantly it runs GNU Hello. Also, emacs works (with the kludgy +`boot' terminal driver) and bash works. + +The simple pipes server works; it will be replaced eventually by the +pflocal server (which isn't done yet). The terminal driver is limping +but working. It doesn't support terminal ioctls yet. A minor bug in +auth has been fixed. boot interprets more Hurd protocols; this was +done to get emacs functioning. Some more-or-less serious bugs in exec +were fixed; they were found by running emacs (a quite large executable +indeed). At bootstrap time, init starts pipes and term itself; +eventually these will be passive translators, but we don't want to +write the new disk format until we're self-hosting or fsck and UX will +get confused. The file proc/primes.c has been documented; thanks go +to Jim Blandy. Some bugs in proc dealing with pgrp and wait were +fixed; a nasty hash table bug was also fixed. The simple shell can do +pipes. Several serious bugs in ufs were fixed dealing with extension +of large files and writes of data not aligned on block boundaries. +The ufs pager was over-serialized; that's been fixed. Directory +lookups and modifications now use mapped I/O directly; this is an +important speed-up. The structure of the pager lockes has been +changed significantly. UFS now supports Mach copying mode +MEMORY_OBJECT_COPY_DELAY; this significantly improves process startup +time. + +Some minor changes have been made to several interfaces. The +interface for fs.defs:dir_readdir has been totally changed. There are +some new fs.defs interfaces: file_check_access, file_notice_changes, +dir_notice_changes. The fsys.defs:fsys_getroot interface was changed +to work correctly. process.defs:proc_setprocargs is renamed, and a +fetch function proc_get_arg_locations is added. The ifsock.defs +interface was simplified. + +Several bugs were fixed in libdiskfs. The new dir_readdir interface +requires new support from format-specific code. Some race conditions +have been fixed. dir-pathtrans.c now deals correctly with multiple +slashes in a row. A new concept called "light references" allows +pagers to remain active without preventing truncate-on-nolinks from +working right. New interfaces in fs.defs are implemented (except +file_notice_changes). Active translator usage has been fixed to work +correctly, but passive translators are still untested. libdiskfs now +thinks it supports S_IFSOCK nodes, but that's untested (of course) +because pflocal isn't done yet. + +The passive translator startup interface in libfshelp has been +radically simplified. The pager library now lets other code set and +changee the attributes on objects, synchronously if desired. An +init/terminate race condition was fixed. The ports library now +allows single-threaded users to work right (they didn't before). The +trivfs library works; see the ifsock server for a simple example of +its use. See term or pipes for more complex examples. + +There is a task list in the file `tasks'; let me know if you are +interested in working on one of these. + diff --git a/hurd/history/hurd-flash4 b/hurd/history/hurd-flash4 new file mode 100644 index 00000000..89ae9848 --- /dev/null +++ b/hurd/history/hurd-flash4 @@ -0,0 +1,101 @@ +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +To: hurd-ann@gnu.ai.mit.edu +Date: Mon, 8 Aug 94 16:01:23 -0400 +Subject: New Hurd Snapshot +X-Shopping-List: + (1) Starboard sauce (2) Cinematic lesions (3) Two-way alphabetic + accordions + + +A new Hurd snapshot has been placed on alpha.gnu.ai.mit.edu in +/pub/gnu/hurd-snap.tar.gz. + +It is expected that the next snapshot after this one will have signals +basically working and thus be usable for a self-hosting system. In +addition, the next snapshot will probably have the current state of +our networking code (which has been proceeding, but has been absent +from the snapshots). + +Here is the NEWS about this current snapshot, however. Because some +big changes were made to the makefile and directory structure, things +might have gotten inadvertently ommitted from the snapshot. If this +happened, please let me know ASAP and I'll fix it and make a new +snapshot. + + -mib + + +August 8, 1994: + +Structural changes: + +Makefiles have been vastly improved and are simpler. The programs +`su', `ps', and `sh' have been moved from separate dirs into `utils'; +the programs `symlink' and `ifsock' have been moved into `trans'. + +Several changes were made to GCC use. You should definitely get GCC +version 2.6.0 now. Version 2.6.1 will have distributed the proper +`specs' file for the i386-gnu target, but it isn't quite ready yet, so +you still have to copy hurd/gcc-specs into +gcc-lib/i386-gnu/2.6.0/specs. + + +Interface changes: + +The tioctl.defs suite is complete now. + +INTR RPC's have been changed; individual RPC's are no longer marked +INTR. Rather, entire interfaces are marked `INTR_INTERFACE' if they +conform to the library's signalling/interruption expectations. + +There is a new magical retry type (for dir_pathtrans and fsys_getroot) +called `machtype' and a new one `/'; the former is for @sys tweaks and +the latter cleans up the retry of root-based symlinks a bit. + +There is a new interface `login.defs'. + +The "dotdot node" is no longer passed at fsys_startup time; instead, +it is passed by fsys_getroot. + + +Library changes: + +The ports library now does death-timeouts for multi-threaded servers; +it doesn't actually work right yet, however. Also the ports library +has new features (soft vs. hard ports; no outstanding ports +notifications) that enable server-death to be done cleanly. (I hope; +libdiskfs and ufs haven't yet been changed to use it, so libports +might not actually have the right facilities yet.) + +The translator startup routines in libfshelp have been vastly improved +(so that they can actually be used). + +Numerous bugfixes in libdiskfs, particularly relating to translator +usage. Use new magical retry type `/' when appropriate. Use new +dotdot node protocol. O_FSYNC and O_NOATIME are now honored properly. +Alternative methods of storing symlinks are now supported through new +hooks. + +The new dotdot protocol is now used by libtrivfs. Also, users of the +library are now able to set the atime and mtime when necessary. + +The special threads version of malloc has been placed back in +libthreads now that the C library uses a Mach-safe version on its own. + + +Program changes: + +The `boot' program no longer implements the tioctl interface now that +the terminal driver works. + +A bug was fixed in the handling of pgrps in `proc'. + +Many bugfixes in term. The tioctl interface is now implemented. EOF +processing is fixed; break characters now work right. Signals and +interruption are now done correctly. VDISCARD works. + +Ufs has Some bigs fixed in dir.c. Filesystem upgraded to BSD 4.4. +There are now some compatibility flags. + +New program dev.trim does a very minimal /dev (but doesn't work yet). +New program dev is an initial (but poor) attempt at a real /dev. diff --git a/hurd/history/hurd-flash5 b/hurd/history/hurd-flash5 new file mode 100644 index 00000000..041a0ef7 --- /dev/null +++ b/hurd/history/hurd-flash5 @@ -0,0 +1,23 @@ +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +Message-Id: <9409210619.AA17570@churchy.gnu.ai.mit.edu> +To: "Lots of potentially interested people and" +Subject: New milestone acheived by the GNU Hurd +X-Tom-Swiftie: "I can't get this fire started," Tom said woodenly. + + +I have just successfully compiled and run a null C program on the +Hurd. This is using GCC native as one would normally use GCC. + +Sadly, it took quite a while (too long, in fact) to read the large +archives that make up the GNU C library, but I think I know where the +substantial inefficiency is. + +Once that is done, I would be happy to label this a "self-hosting +system". But not just yet. + +The last bug preventing this was an error in dealing with files over +about 8 M; this came about because in order to link a program one +needed the GNU C library, which is over 9M when symbols are included. + + -mib + diff --git a/hurd/history/hurd-flash6 b/hurd/history/hurd-flash6 new file mode 100644 index 00000000..e774714e --- /dev/null +++ b/hurd/history/hurd-flash6 @@ -0,0 +1,46 @@ +Return-Path: +Received: from pdxgate.cs.pdx.edu by gnurd with uucp + (Linux Smail3.1.28.1 #14) id m0r66pm-00010fC; Fri, 11 Nov 94 17:00 PST +Received: from cs.pdx.edu by pdxgate.cs.pdx.edu (4.1/CATastrophe-9/19/94-U) + id AA05257; Fri, 11 Nov 94 16:40:48 PST +Received: from churchy.gnu.ai.mit.edu by cs.pdx.edu (4.1/CATastrophe-9/19/94-P) + id AA02600; Fri, 11 Nov 94 16:40:22 PST +Received: by churchy.gnu.ai.mit.edu (5.65/4.0) + id ; Fri, 11 Nov 94 16:45:35 -0500 +Received: by churchy.gnu.ai.mit.edu (5.65/4.0) + id ; Fri, 11 Nov 94 16:38:44 -0500 +Date: Fri, 11 Nov 94 16:38:44 -0500 +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +Message-Id: <9411112138.AA12580@churchy.gnu.ai.mit.edu> +To: hurd-ann@gnu.ai.mit.edu, hurd-dev@gnu.ai.mit.edu, info-gnu@prep.ai.mit.edu +Subject: New Hurd Snapshot +X-Shopping-List: + (1) Horrendous collision devotions (2) Wondrous consolation (3) + Conscious cooking auctions +X-Filter: mailagent [version 3.0 PL19] for trent@gnurd.uu.pdx.edu + + +A new Hurd snapshot has been placed on alpha.gnu.ai.mit.edu. There +may be unforseen problems with this snapshot, so the old one has been +left. You may fetch this snapshot via anonymous FTP in the file +/gnu/hurd-snap.tar.gz. + +The Hurd requires a modified version of MiG; you can get it by +anonymous ftp to kahlua.cs.utah.edu in /pub/mach/mach4-UK02p6.tar.gz. +Note that we are not yet using Mach4 for the Hurd, but we plan to +switch as soon as its feasible. + +Other necessary software to run this snapshot include the latest +snapshot of binutils/ld/gas source from Cygnus and the latest GCC. +(Problems have been reported with GCC 2.6.1; you might want to wait +until 2.6.2 is released.) And, of course, you also need the latest +test version of the GNU C Library, found on alpha.gnu.ai.mit.edu. + +This is not yet a real release; it is certainly not up to the quality +of even a hesitant alpha release. But it may be useful for +educational value or to help with the Hurd effort. + +I will be out of town for most of the rest of the year; I will be +reading email but I may not be able to help with problems. Sorry... + + -mib diff --git a/hurd/history/hurd-flash7 b/hurd/history/hurd-flash7 new file mode 100644 index 00000000..ce6e08d2 --- /dev/null +++ b/hurd/history/hurd-flash7 @@ -0,0 +1,17 @@ +Date: Wed, 12 Apr 1995 15:08:18 -0400 +From: Michael I Bushnell +To: hurd-ann@duality.gnu.ai.mit.edu +Subject: New Hurd Snapshot available + +A new hurd snapshot is now available from +ftp://alpha.gnu.ai.mit.edu/gnu/hurd-snap.tar.gz. + +This snapshot contains many improvements over the last one, and is +also probably easier to compile. + +This snapshot must be used with the most recent libc snapshot, +ftp://alpha.gnu.ai.mit.edu/gnu/libc-950411.tar.gz. Previous versions +of the library will not work right. + +If any files are discovered to be missing, please let me know asap. + diff --git a/hurd/history/hurd-flash8 b/hurd/history/hurd-flash8 new file mode 100644 index 00000000..555186ec --- /dev/null +++ b/hurd/history/hurd-flash8 @@ -0,0 +1,73 @@ +Date: Sun, 23 Jul 1995 16:27:46 -0400 +Message-Id: <199507232027.QAA09306@geech.gnu.ai.mit.edu> +From: Michael I Bushnell +To: hurd-ann@gnu.ai.mit.edu +Subject: Hurd snapshot! +X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+ ++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv ++ b+++ !D B-- e+ u++(*) h* f? r n y++ +X-Zippy-Says: I just had a NOSE JOB!! +Sender: owner-abshurd@cs.pdx.edu +Precedence: bulk + + +I have just put a new Hurd snapshot on alpha.gnu.ai.mit.edu in +/gnu/hurd-snap-950723.tar.gz. + +You will also need the new libc snapshot, which should appear in the +same place today. Older libc snapshots will not be happy. + +The binary images (hurd-floppy.fs.gz and hurd-image.tar.gz) have not +been updated. It is difficult to use the Hurd standalon, because the +Mach boot loaders can now no longer boot the Hurd. A new boot loader +is nearly finished. Perhaps we can make new binary images then, or a +volunteer might take over this useful work. (Hint, hint.) + +Michael + + + +Here is the NEWS: + +July 23, 1995 + +Shared libraries now work; use -static to link programs and avoid the +shared libraries. The Hurd programs are normally built static; this +will probably change soon. + +The ext2fs server now works, as do the tools to manipulate ext2fs +filesystems. A snapshot of the tools will be made soon under separate +cover. Many thanks to Ted Ts'o for his valuable work on the tools. + +Readers of the Makefiles will notice that we now generate dependencies +automatically. + +The old netserv library is gone. + +The `boot' hack has been modified slightly to avoid the normalq libc startup +files, because they no longer work with UX. + +Some small bugs have been fixed in the devio server. + +The ports library has been totally rewritten; new features permit +servers to have greater control over thread RPC's and port creation. + +The fshelp library now does most of the work for translator +interaction; it's simpler now too. Filesystems have much less work to +do; the relevant code in libdiskfs is now understanble instead of +unparseable chaos. + +The ports library provides for timeouts; the diskfs library almost +uses it, but because of a bug, it's disabled for now. + +Filesystems are now expected to sync themselves if necessary; the new +fsys_set_options RPC provides for changeing (or cancelling) the sync +intervale. The diskfs library does this for you. The update program +is no longer necessary. + +A small bug in the proc server has been hacked around; the real fix +will come later. + +Many important bugs in the C library have been fixed since the last +snapshot; perhaps all of them. ;-) + diff --git a/hurd/history/hurd-flash9 b/hurd/history/hurd-flash9 new file mode 100644 index 00000000..1ff32ba9 --- /dev/null +++ b/hurd/history/hurd-flash9 @@ -0,0 +1,39 @@ +Date: Wed, 29 Nov 1995 13:13:23 -0500 +Message-Id: <199511291813.NAA10983@duality.gnu.ai.mit.edu> +From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +To: hurd-ann@gnu.ai.mit.edu (and others) +Subject: Announcement +X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+ ++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv ++ b+++ !D B-- e+ u++(*) h* f? r n y++ +X-Windows: The Cutting Edge of Obsolescence. +Sender: owner-abshurd@cs.pdx.edu +Precedence: bulk + + +The Hurd has succesfully completed its first FTP: + +bash# ftp 128.52.46.31 +Connected to 128.52.46.31. +220 albert.gnu.ai.mit.edu FTP server (Version 5.60) ready. +Name (128.52.46.31:root): +331 Password required for root. +Password:230 User root logged in. +ftp> cd ~mib +250 CWD command successful. +ftp> get ftptest +200 PORT command successful. +150 Opening ASCII mode data connection for ftptest (16 bytes). +226 Transfer complete. +17 bytes received in 0.07 secs (0.24 Kbytes/sec) +ftp> quit +221 Goodbye. +bash# cat ftptest +this is a test. +bash# + + +Tre cool. + +Michael + -- cgit v1.2.3 From daf515b3117746bc50e3d839496f57a302ef0a0d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 12:49:14 +0100 Subject: Integrate howto/subhurd.html. --- howto/subhurd.html | 89 ------------------------------------- hurd/subhurd.mdwn | 3 +- hurd/subhurd/running_a_subhurd.mdwn | 42 +++++++++++++++++ 3 files changed, 43 insertions(+), 91 deletions(-) delete mode 100644 howto/subhurd.html create mode 100644 hurd/subhurd/running_a_subhurd.mdwn (limited to 'hurd') diff --git a/howto/subhurd.html b/howto/subhurd.html deleted file mode 100644 index 54aa3b3c..00000000 --- a/howto/subhurd.html +++ /dev/null @@ -1,89 +0,0 @@ - - - - - GNU Hurd - Free Software Foundation (FSF) - - - - - - - - - - -
-The GNU Hurd
-

-Whatis?
-Howto?
-

- -

- -Acknowledgements
- -

 -

Running a Subhurd

-

By Roland McGrath

-

The most useful thing you can do when trying to troubleshoot the boot -sequence of the Hurd is try to run your the system in a -sub-hurd, while watching it using ps and gdb from the working hurd. Since -the sub-hurd is never going to make it all the way up, you don't even -really need to make a separate filesystem for it; you can just boot the -sub-hurd read-only on your main root filesystem if you like.

- -

The way to boot the sub-hurd is with `boot'. I would suggest something -like this: boot -d -I -Tdevice /boot/servers.boot hd0s6

- -

The -d says to pause before the start-up of each server and wait for you to -hit return, which gives you time to go attach gdb to the task before it -starts running. The -I says to leave the terminal signals normal, so -hitting C-z will suspend boot rather than sending a C-z to the virtual -console device of the sub-hurd. (Note that suspending boot does not -suspend the sub-hurd, just boot itself; boot acts as the server for device -access from the sub-hurd, so the sub-hurd's attempts to write to its -console or open devices block while boot is suspended.)

- -

When you do `ps -A' on the main hurd, the sub-hurd tasks will appear as -unknown processes. You can figure out which is which just by looking at -the order of unknown processes that appear with higher PIDs than the boot -process. They appear in the order you see in the "bootstrap: ..." -messages, i.e. the first unknown after boot will be ext2fs.static, the -second exec, then init, then proc.

- - -
- -Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 1998, 1999, 2007 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved.

-Updated: - -$Date$ $Author$ - -

-
- - - diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index 8816e312..d2b80cf9 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -118,5 +118,4 @@ characteristic thread counts. Read about using a subhurd for [[debugging_purposes|debugging/subhurd]]. -Roland's [tutorial](http://www.gnu.org/software/hurd/howto/subhurd.html) on -setting up sub-hurds. +Roland's tutorial about [[running_a_subhurd]]. diff --git a/hurd/subhurd/running_a_subhurd.mdwn b/hurd/subhurd/running_a_subhurd.mdwn new file mode 100644 index 00000000..5d9693cd --- /dev/null +++ b/hurd/subhurd/running_a_subhurd.mdwn @@ -0,0 +1,42 @@ +[[meta copyright="Copyright © 1998, 1999, 2007, 2008 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="Running a Subhurd"]] + +By Roland McGrath. + +The most useful thing you can do when trying to troubleshoot the boot +sequence of the Hurd is try to run your the system in a +sub-hurd, while watching it using ps and gdb from the working hurd. Since +the sub-hurd is never going to make it all the way up, you don't even +really need to make a separate filesystem for it; you can just boot the +sub-hurd read-only on your main root filesystem if you like. + +The way to boot the sub-hurd is with `boot`. I would suggest something +like this: + + boot -d -I -Tdevice /boot/servers.boot hd0s6 + +The -d says to pause before the start-up of each server and wait for you to +hit return, which gives you time to go attach gdb to the task before it +starts running. The -I says to leave the terminal signals normal, so +hitting C-z will suspend boot rather than sending a C-z to the virtual +console device of the sub-hurd. (Note that suspending boot does not +suspend the sub-hurd, just boot itself; boot acts as the server for device +access from the sub-hurd, so the sub-hurd's attempts to write to its +console or open devices block while boot is suspended.) + +When you do `ps -A` on the main hurd, the sub-hurd tasks will appear as +unknown processes. You can figure out which is which just by looking at +the order of unknown processes that appear with higher PIDs than the boot +process. They appear in the order you see in the "bootstrap: ..." +messages, i.e. the first unknown after boot will be ext2fs.static, the +second exec, then init, then proc. -- cgit v1.2.3 From a3bbfa6bc8a3abd8dd3c56fd8fe975028f6fa005 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 12:56:40 +0100 Subject: Integrate whatis/translator.html. --- hurd/documentation.mdwn | 2 + hurd/documentation/translators.html | 236 +++++++++++++++++++++++++++++ hurd/translator.mdwn | 2 + whatis/translator.html | 290 ------------------------------------ 4 files changed, 240 insertions(+), 290 deletions(-) create mode 100644 hurd/documentation/translators.html delete mode 100644 whatis/translator.html (limited to 'hurd') diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index a32bc84f..be0874e7 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -24,6 +24,8 @@ is included in the section entitled * [[*The_Hurd*|hurd-talk]], a presentation by Marcus Brinkmann. + * A document about *[[translators]]* by Marcus Brinkmann. + * [[*A_Critique_of_the_GNU_Hurd_Multi-server_Operating_System*|critique]], an analysis of the GNU Hurd on GNU Mach system, written by Neal Walfield and Marcus Brinkmann. diff --git a/hurd/documentation/translators.html b/hurd/documentation/translators.html new file mode 100644 index 00000000..4e47a9c0 --- /dev/null +++ b/hurd/documentation/translators.html @@ -0,0 +1,236 @@ +[[meta copyright="Copyright © 1998, 1999, 2007, 2008 Free Software Foundation, +Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="Translators"]] + +By Marcus Brinkmann. + + +

Concept

+

+Before we take a closer look at translators, let us consider regular +filesystems. A filesystem is store for a hierarchical tree of directories +and files. You access directories and files by a special character string, +the path. Furthermore, there are symbolic links to refer to one file at +several places in the tree, there are hard links to give one and the same +file several names. There are also special device files for communication +with the hardware device drivers of the kernel, and there are mount points +to include other stores in the directory tree. Then there are obscure +objects like fifos and hard links.

+

+Although these objects are very different, they share some common +properties, for example, they have all an owner and a group associated with +them as well as access rights (permissions). This information is written in +inodes. This is a actually a further commonality: Every object has exactly +one inode associated with it (hard links are somewhat special as they share +one and the same inode). Sometimes, the inode has further information +stored in it. For example, the inode can contain the target of a symbolic +link.

+

+However, these commonalities are usually not exploited in the +implementations, despite the common programming interface to them. All +inodes can be accessed through the standard POSIX calls, for example +read() and write(). For example, to add a new +object type (for example a new link type) to a common monolithic unix +kernel, you would need to modify the code for each filesystem +seperately.

+

+In the Hurd, things work differently. Although in the Hurd a special +filesystem server can exploit special properties of standard object types +like links (in the ext2 filesystem with fast links, for example), it has a +general interface to add such features without modifying existing code.

+

+The trick is to allow a program to be inserted between the actual content of +a file and the user accessing this file. Such a program is called a +translator, because it is able to process the incoming requests in many +different ways. In other words, a translator is a Hurd server which provides +the basic filesystem interface.

+

+Translators have very interesting properties. From the kernels point of +view, they are just another user process. This means, translators can be run +by any user. You don't need root priviligies to install or modify a +translator, you only need the access rights for the underlying inode the +translator is attached to. Many translators don't require an actual file to +operate, they can provide information by their own means. This is why +the information about translators is stored in the inode.

+

+Translators are responsible to serve all file system operations that involve +the inode they are attached to. Because they are not restricted to the usual +set of objects (device file, link etc), they are free to return anything +that makes sense to the programmer. One could imagine a translator that +behaves like a directory when accessed by cd or +ls and at the same time behaves like a file when accessed by +cat.

+

Examples

+

Mount Points

+

+A mount point can be seen as an inode that has a special translator attached +to it. Its purpose would be to translate filesystem operations on the mount +point in filesystem operations on another store, let's say, another +partition.

+

+Indeed, this is how filesystems are implemented under the Hurd. A +filesystem is a translator. This translator takes a store as its argument, +and is able to serve all filesystem operations transparently.

+

Device Files

+

+There are many different device files, and in systems with a monolithical +kernel, they are all provided by the kernel itself. In the Hurd, all device +files are provided by translators. One translator can provide support for +many similar device files, for example all hard disk partitions. This way, +the number of actual translators needed is quite small. However, note that +for each device file accessed, a seperate translator task is started. +Because the Hurd is heavily multi threaded, this is very cheap.

+

+When hardware is involved, a translator usually starts to communicate with +the kernel to get the data from the hardware. However, if no hardware access +is necessary, the kernel does not need to be involved. For example, +/dev/zero does not require hardware access, and can therefore +be implemented completely in user space.

+

Symbolic Links

+

+A symbolic link can be seen as a translator. Accesing the symbolic link +would start up the translator, which would forward the request to the +filesystem that contains the file the link points to.

+

+However, for better performance, filesystems that have native support +for symbolic links can take advantage of this feature and implement +symbolic links differently. Internally, accessing a symbolic link would not +start a new translator process. However, to the user, it would still look +as if a passive translator is involved (see below for an explanation what a +passsive translator is).

+

+Because the Hurd ships with a symlink translator, any filesystem server that +provides support for translators automatically has support for symlinks (and +firmlinks, and device files etc)! This means, you can get a working +filesystem very fast, and add native support for symlinks and other features +later.

+

Passive Translators, Active Translators

+

+There are two types of translators, passive and active. They are really +completely different things, so don't mix them up, but they have a close +relation to each other.

+

Active Translators

+

+An active translator is a running translator process, as introduced above. +You can set and remove active translators using the +settrans -a +command. The -a option is necessary to tell +settrans that you want to modify the active translator.

+

+The settrans command takes three kind of arguments. First, you +can set options for the settrans command itself, like +-a to modify the active translator. Then you set the inode you +want to modify. Remember that a translator is always associated with an +inode in the directory hierarchy. You can only modify one inode at a time. +If you do not specify any more arguments, settrans will try to +remove an existing translator. How hard it tries depends on the force +options you specify (if the translator is in use by any process, you will +get "device or resource busy" error message unless you force it to go away).

+

+But if you specify further arguments, it will be interpreted as a command +line to run the translator. This means, the next argument is the filename of +the translator executable. Further arguments are options to the translator, +and not to the settrans command.

+

+For example, to mount an ext2fs partition, you can run +settrans -a -c /mnt /hurd/ext2fs /dev/hd2s5. The +-c option will create the mount point for you if it doesn't +exist already. This does not need to be a directory, by the way. To unmount, +you would try settrans -a /mnt.

+

Passive Translators

+

+A passive translator is set and modified with the same syntax as the active +translator (just leave away the -a, so everything said above is +true for passive translators, too. However, there is a difference: passive +translators are not yet started.

+

+This makes sense, because this is what you usually want. You don't want the +partition mounted unless you really access files on this partition. You +don't want to bring up the network unless there is some traffic and so +on.

+

+Instead, the first time the passive translator is accessed, it is +automatically read out of the inode and an active translator is started on +top of it using the command line that was stored in the inode. This is +similar to the Linux automounter functionality. However, it does not come as +an additional bonus that you have to set up manually, but an integral part of +the system. So, setting passive translators defers starting the translator +task until you really need it. By the way, if the active translator dies for +some reason, the next time the inode is accessed the translator is +restarted.

+

+There is a further difference: active translators can die or get lost. As +soon as the active translator process is killed (for example, because you +reboot the machine) it is lost forever. Passive translators are not transient +and stay in the inode during reboots until you modify them with the +settrans program or delete the inodes they are attached to. +This means, you don't need to maintain a configuration file with your mount +points.

+

+One last point: Even if you have set a passive translator, you can still +set a different active translator. Only if the translator is automatically +started because there was no active translator the time the inode was +accessed the passive translator is considered.

+

Managing Translators

+

+As mentioned above, you can use +settrans +to set and alter passive and active translators. There are a lot of options +to change the behaviour of settrans in case something goes +wrong, and to conditionalize its action. Here are some common usages:

+
  • settrans -c /mnt /hurd/ext2fs /dev/hd2s5 mounts a +partition, the translator will stay across reboots.
    • +
  • settrans -a /mnt /hurd/ext2fs ~/dummy.fs mounts a +filesystem inside a data file, the translator will go away if it dies.
    • +
  • settrans -fg /nfs-data forces a translator to go away.
    • +
+

+You can use the showtrans +command to see if a translator is attached to an inode. This will only show +you the passive translator though.

+

+You can change the options of an active (filesystem) translator with +fsysopts without actually restarting it. This is very +convenient. For example, you can do what is called "remounting a +partition read-only" under Linux simply by running fsysopts +/mntpoint --readonly. The running active translator +will change its behaviour according to your request if possible. +fsysopts /mntpoint without a parameter shows you the current +settings.

+

Examples

+

+I recommend that you start by reading the /bin/mount command, +it is only a small script. Because setting filesystem translators is +similar to mounting partitions, you can easily grasp the concept this way. +Make a file system image with dd if=/dev/zero of=dummy.fs bs=1024k +count=8; mke2fs dummy.fs and "mount" it with settrans -c dummy +/hurd/ext2fs `pwd`/dummy.fs. Note that the translator is not started +yet, no new ext2fs process is running (verify with ps +Aux). Check that everything is correct using showtrans

+

+Now type ls dummy and you will notice the short delay that +occurs while the translator is started. After that, there will be no more +delays accessing dummy. Under Linux, one would say that you automounted a +loop file system. Check with ps Aux that there is an ext2fs +dummy process up and running now. Now put some files into the new +directory. Try to make the filesystem read-only with fsysopts. +Note how further write attempts fail now. Try to kill the active translator +with settrans -g.

+

+You should have some understanding of what is going on now. Now remember +that this was only one special server, the Hurd ext2fs server. +There are many more server in the hurd directory. Some of them +are for filesystems. Some are needed for file system features like links. +Some are needed for device files. Some are useful for networking. Imagine +"mounting" an FTP Server with settrans and downloading files +simply with the standard cp command. Or editing your web sites +with emacs /ftp/homepage.my.server.org/index.html!

diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 889f02a6..1a987b09 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -40,6 +40,8 @@ Also there is an [[writing/example]] about how to write a simple translator. See some [[examples]] about how to use translators. +Marcus Brinkmann has written a document about [[documentation/translators]]. + # Existing Translators diff --git a/whatis/translator.html b/whatis/translator.html deleted file mode 100644 index 516d5049..00000000 --- a/whatis/translator.html +++ /dev/null @@ -1,290 +0,0 @@ - - - - - GNU Hurd - Free Software Foundation (FSF) - - - - - - - - - - -
-The GNU Hurd
-

-Whatis?
-Howto?
-

- -

- -Acknowledgements
- -

 -

GNU Hurd

 -

Translators

-

By Marcus Brinkmann

- -

Concept

-

-Before we take a closer look at translators, let us consider regular -filesystems. A filesystem is store for a hierarchical tree of directories -and files. You access directories and files by a special character string, -the path. Furthermore, there are symbolic links to refer to one file at -several places in the tree, there are hard links to give one and the same -file several names. There are also special device files for communication -with the hardware device drivers of the kernel, and there are mount points -to include other stores in the directory tree. Then there are obscure -objects like fifos and hard links.

-

-Although these objects are very different, they share some common -properties, for example, they have all an owner and a group associated with -them as well as access rights (permissions). This information is written in -inodes. This is a actually a further commonality: Every object has exactly -one inode associated with it (hard links are somewhat special as they share -one and the same inode). Sometimes, the inode has further information -stored in it. For example, the inode can contain the target of a symbolic -link.

-

-However, these commonalities are usually not exploited in the -implementations, despite the common programming interface to them. All -inodes can be accessed through the standard POSIX calls, for example -read() and write(). For example, to add a new -object type (for example a new link type) to a common monolithic unix -kernel, you would need to modify the code for each filesystem -seperately.

-

-In the Hurd, things work differently. Although in the Hurd a special -filesystem server can exploit special properties of standard object types -like links (in the ext2 filesystem with fast links, for example), it has a -general interface to add such features without modifying existing code.

-

-The trick is to allow a program to be inserted between the actual content of -a file and the user accessing this file. Such a program is called a -translator, because it is able to process the incoming requests in many -different ways. In other words, a translator is a Hurd server which provides -the basic filesystem interface.

-

-Translators have very interesting properties. From the kernels point of -view, they are just another user process. This means, translators can be run -by any user. You don't need root priviligies to install or modify a -translator, you only need the access rights for the underlying inode the -translator is attached to. Many translators don't require an actual file to -operate, they can provide information by their own means. This is why -the information about translators is stored in the inode.

-

-Translators are responsible to serve all file system operations that involve -the inode they are attached to. Because they are not restricted to the usual -set of objects (device file, link etc), they are free to return anything -that makes sense to the programmer. One could imagine a translator that -behaves like a directory when accessed by cd or -ls and at the same time behaves like a file when accessed by -cat.

-

Examples

-

Mount Points

-

-A mount point can be seen as an inode that has a special translator attached -to it. Its purpose would be to translate filesystem operations on the mount -point in filesystem operations on another store, let's say, another -partition.

-

-Indeed, this is how filesystems are implemented under the Hurd. A -filesystem is a translator. This translator takes a store as its argument, -and is able to serve all filesystem operations transparently.

-

Device Files

-

-There are many different device files, and in systems with a monolithical -kernel, they are all provided by the kernel itself. In the Hurd, all device -files are provided by translators. One translator can provide support for -many similar device files, for example all hard disk partitions. This way, -the number of actual translators needed is quite small. However, note that -for each device file accessed, a seperate translator task is started. -Because the Hurd is heavily multi threaded, this is very cheap.

-

-When hardware is involved, a translator usually starts to communicate with -the kernel to get the data from the hardware. However, if no hardware access -is necessary, the kernel does not need to be involved. For example, -/dev/zero does not require hardware access, and can therefore -be implemented completely in user space.

-

Symbolic Links

-

-A symbolic link can be seen as a translator. Accesing the symbolic link -would start up the translator, which would forward the request to the -filesystem that contains the file the link points to.

-

-However, for better performance, filesystems that have native support -for symbolic links can take advantage of this feature and implement -symbolic links differently. Internally, accessing a symbolic link would not -start a new translator process. However, to the user, it would still look -as if a passive translator is involved (see below for an explanation what a -passsive translator is).

-

-Because the Hurd ships with a symlink translator, any filesystem server that -provides support for translators automatically has support for symlinks (and -firmlinks, and device files etc)! This means, you can get a working -filesystem very fast, and add native support for symlinks and other features -later.

-

Passive Translators, Active Translators

-

-There are two types of translators, passive and active. They are really -completely different things, so don't mix them up, but they have a close -relation to each other.

-

Active Translators

-

-An active translator is a running translator process, as introduced above. -You can set and remove active translators using the -settrans -a -command. The -a option is necessary to tell -settrans that you want to modify the active translator.

-

-The settrans command takes three kind of arguments. First, you -can set options for the settrans command itself, like --a to modify the active translator. Then you set the inode you -want to modify. Remember that a translator is always associated with an -inode in the directory hierarchy. You can only modify one inode at a time. -If you do not specify any more arguments, settrans will try to -remove an existing translator. How hard it tries depends on the force -options you specify (if the translator is in use by any process, you will -get "device or resource busy" error message unless you force it to go away).

-

-But if you specify further arguments, it will be interpreted as a command -line to run the translator. This means, the next argument is the filename of -the translator executable. Further arguments are options to the translator, -and not to the settrans command.

-

-For example, to mount an ext2fs partition, you can run -settrans -a -c /mnt /hurd/ext2fs /dev/hd2s5. The --c option will create the mount point for you if it doesn't -exist already. This does not need to be a directory, by the way. To unmount, -you would try settrans -a /mnt.

-

Passive Translators

-

-A passive translator is set and modified with the same syntax as the active -translator (just leave away the -a, so everything said above is -true for passive translators, too. However, there is a difference: passive -translators are not yet started.

-

-This makes sense, because this is what you usually want. You don't want the -partition mounted unless you really access files on this partition. You -don't want to bring up the network unless there is some traffic and so -on.

-

-Instead, the first time the passive translator is accessed, it is -automatically read out of the inode and an active translator is started on -top of it using the command line that was stored in the inode. This is -similar to the Linux automounter functionality. However, it does not come as -an additional bonus that you have to set up manually, but an integral part of -the system. So, setting passive translators defers starting the translator -task until you really need it. By the way, if the active translator dies for -some reason, the next time the inode is accessed the translator is -restarted.

-

-There is a further difference: active translators can die or get lost. As -soon as the active translator process is killed (for example, because you -reboot the machine) it is lost forever. Passive translators are not transient -and stay in the inode during reboots until you modify them with the -settrans program or delete the inodes they are attached to. -This means, you don't need to maintain a configuration file with your mount -points.

-

-One last point: Even if you have set a passive translator, you can still -set a different active translator. Only if the translator is automatically -started because there was no active translator the time the inode was -accessed the passive translator is considered.

-

Managing Translators

-

-As mentioned above, you can use -settrans -to set and alter passive and active translators. There are a lot of options -to change the behaviour of settrans in case something goes -wrong, and to conditionalize its action. Here are some common usages:

-
  • settrans -c /mnt /hurd/ext2fs /dev/hd2s5 mounts a -partition, the translator will stay across reboots.
    • -
  • settrans -a /mnt /hurd/ext2fs ~/dummy.fs mounts a -filesystem inside a data file, the translator will go away if it dies.
    • -
  • settrans -fg /nfs-data forces a translator to go away.
    • -
-

-You can use the showtrans -command to see if a translator is attached to an inode. This will only show -you the passive translator though.

-

-You can change the options of an active (filesystem) translator with -fsysopts without actually restarting it. This is very -convenient. For example, you can do what is called "remounting a -partition read-only" under Linux simply by running fsysopts -/mntpoint --readonly. The running active translator -will change its behaviour according to your request if possible. -fsysopts /mntpoint without a parameter shows you the current -settings.

-

Examples

-

-I recommend that you start by reading the /bin/mount command, -it is only a small script. Because setting filesystem translators is -similar to mounting partitions, you can easily grasp the concept this way. -Make a file system image with dd if=/dev/zero of=dummy.fs bs=1024k -count=8; mke2fs dummy.fs and "mount" it with settrans -c dummy -/hurd/ext2fs `pwd`/dummy.fs. Note that the translator is not started -yet, no new ext2fs process is running (verify with ps -Aux). Check that everything is correct using showtrans

-

-Now type ls dummy and you will notice the short delay that -occurs while the translator is started. After that, there will be no more -delays accessing dummy. Under Linux, one would say that you automounted a -loop file system. Check with ps Aux that there is an ext2fs -dummy process up and running now. Now put some files into the new -directory. Try to make the filesystem read-only with fsysopts. -Note how further write attempts fail now. Try to kill the active translator -with settrans -g.

-

-You should have some understanding of what is going on now. Now remember -that this was only one special server, the Hurd ext2fs server. -There are many more server in the hurd directory. Some of them -are for filesystems. Some are needed for file system features like links. -Some are needed for device files. Some are useful for networking. Imagine -"mounting" an FTP Server with settrans and downloading files -simply with the standard cp command. Or editing your web sites -with emacs /ftp/homepage.my.server.org/index.html!

- -
- -Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 1998, 1999, 2007 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved.

-Updated: - -$Date$ $Author$ - -

-
- - - -- cgit v1.2.3 From f0a012de3139ce8e589d8d8bee23ee3a64a2f818 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 13:17:45 +0100 Subject: Change/remove some no-longer-valid links. --- Hurd/TranslatorExamples.mdwn | 4 ---- contributing.mdwn | 4 ++-- hurd.mdwn | 4 ++-- hurd/debugging/subhurd.mdwn | 2 +- news/2002-03-23.mdwn | 5 ++--- news/2002-10-03.mdwn | 4 ++-- news/2006-04-27.mdwn | 6 +++--- news/2007-01-07.mdwn | 10 ++++------ news/2007-03-14.mdwn | 6 +++--- 9 files changed, 19 insertions(+), 26 deletions(-) (limited to 'hurd') diff --git a/Hurd/TranslatorExamples.mdwn b/Hurd/TranslatorExamples.mdwn index 227e9275..0c2e5741 100644 --- a/Hurd/TranslatorExamples.mdwn +++ b/Hurd/TranslatorExamples.mdwn @@ -59,7 +59,3 @@ hurd:~/ftp# cd 128.101.80.131 ## Articles about translators * [The GNU Hurd - Translators by Gael le Mignot](http://kilobug.free.fr/hurd/pres-en/html/node8.html) - -* [Translators by Marcus Brinkmann](http://www.gnu.org/software/hurd/whatis/translator.html) - --- [[Main/LucasNussbaum]] - 28 Feb 2004 diff --git a/contributing.mdwn b/contributing.mdwn index f1003389..aac255bd 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -36,8 +36,8 @@ For one there's the implementation of the *[[Hurd]] running on the [[microkernel/mach/GNU_Mach]] microkernel*. This is what is commonly meant when people are talking about GNU/Hurd systems. -This system has mostly been designed and implemented [in the -'90s](http://www.gnu.org/software/hurd/history.html). It works and is usable. +This system has mostly been designed and implemented +[[in_the_'90s|hurd/history]]. It works and is usable. For example, these web pages are rendered on a [GNU/Hurd system](http://www.bddebian.com/cgi-bin/uptime). diff --git a/hurd.mdwn b/hurd.mdwn index 3c65bb4e..e7f0ac92 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -44,10 +44,10 @@ in the *unstable* branch of the Debian archive. # Understanding * Introductory Material - * [Marcus Brinkmann](http://www.gnu.org/software/hurd/hurd-talk.html) + * [[Documentation]] * [Gaël Le Mignot](http://kilobug.free.fr/hurd/pres-en/slides/slides.html) * Architecture - * [Towards a New Strategy of OS Design](http://www.gnu.org/software/hurd/hurd-paper.html) by Thomas Bushnell, BSG. + * [[Towards_a_New_Strategy_of_OS_Design|documentation/hurd-paper]] by Thomas Bushnell, BSG. * Marcus Brinkmann's [revisit](http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00651.html) * Jonathan S. Shapiro [comments](http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00654.html) * [[Critique]] - Analysis diff --git a/hurd/debugging/subhurd.mdwn b/hurd/debugging/subhurd.mdwn index caad950b..7b5b07b1 100644 --- a/hurd/debugging/subhurd.mdwn +++ b/hurd/debugging/subhurd.mdwn @@ -85,6 +85,6 @@ W3 Sources: -* +* [[subhurd/running_a_subhurd]] * * [[Thomas_Schwinge|tschwinge]]'s mind diff --git a/news/2002-03-23.mdwn b/news/2002-03-23.mdwn index 2f36271b..9820b8c5 100644 --- a/news/2002-03-23.mdwn +++ b/news/2002-03-23.mdwn @@ -8,7 +8,6 @@ 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]]."]]"""]] -Added The Hurd -Hacking Guide to the documentation section. Thanks to Wolfgang -Jährling for providing this introduction into GNU/Hurd and Mach +Added the [[hurd/Hurd_Hacking_Guide]] to the documentation section. Thanks to +Wolfgang Jährling for providing this introduction into GNU/Hurd and Mach programming! diff --git a/news/2002-10-03.mdwn b/news/2002-10-03.mdwn index 8696a43e..40f4e1b6 100644 --- a/news/2002-10-03.mdwn +++ b/news/2002-10-03.mdwn @@ -8,8 +8,8 @@ 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]]."]]"""]] -A new article about the authentication -server has been added to the web pages. It resembles the talk +A new article about [[the_authentication_server|hurd/documentation/auth]] +has been added to the web pages. It resembles the talk about the same topic which was given at the Libre Software Meeting, therefore the target audience is mostly programmers which want to learn about the details of authentication in the Hurd. diff --git a/news/2006-04-27.mdwn b/news/2006-04-27.mdwn index 86073ca5..dc52c527 100644 --- a/news/2006-04-27.mdwn +++ b/news/2006-04-27.mdwn @@ -13,9 +13,9 @@ Summer of Code, under the aegis of the GNU project.

The following is a list of items you might want to work on. If you want to modify or extend these tasks or have your own ideas what to work on, please -feel invited to contact us on the bug-hurd mailing list or the #hurd IRC channel.

+feel invited to contact us on the +[[bug-hurd_mailing_list|mailing_lists/bug-hurd]] or +the [[#hurd_IRC_channel|irc]].

    diff --git a/news/2007-01-07.mdwn b/news/2007-01-07.mdwn index 7621ebde..75eb7d01 100644 --- a/news/2007-01-07.mdwn +++ b/news/2007-01-07.mdwn @@ -8,9 +8,7 @@ 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]]."]]"""]] -A number of GNU Hurd developers will again (as already in the previous -years) meet at the time of the FOSDEM 2007, which will take place from -2007-02-24 to 25 in Brussels, Belgium. -This -wiki page has some details. Contact -us if you are interested in meeting with us. +A number of GNU Hurd developers will again (as already in the previous years) +meet at the time of the FOSDEM 2007, which will take place from 2007-02-24 to +25 in Brussels, Belgium. [[This_wiki_page|community/meetings/fosdem_2007]] has +some details. [[Contact_us]] if you are interested in meeting with us. diff --git a/news/2007-03-14.mdwn b/news/2007-03-14.mdwn index 989afedc..3b1b2ad3 100644 --- a/news/2007-03-14.mdwn +++ b/news/2007-03-14.mdwn @@ -13,9 +13,9 @@ Summer of Code, under the aegis of the GNU project.

    The following is a list of items you might want to work on. If you want to modify these task proposals or have your own ideas on what to work, then please -don't hesitate to contact us on the bug-hurd mailing list or the #hurd IRC channel.

    +don't hesitate to contact us on the +[[bug-hurd_mailing_list|mailing_lists/bug-hurd]] or +the [[#hurd_IRC_channel|irc]].

      -- cgit v1.2.3