From 0d41c97e727159917752e7d9f18dbb7a018d157d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 23 Oct 2010 22:37:54 +0200 Subject: hurd/translator/ext2fs/large_stores: Copyright as per Ogi's email. , 2010-09-08. --- hurd/translator/ext2fs/large_stores.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'hurd') diff --git a/hurd/translator/ext2fs/large_stores.txt b/hurd/translator/ext2fs/large_stores.txt index e17a02a5..6e7ffc6f 100644 --- a/hurd/translator/ext2fs/large_stores.txt +++ b/hurd/translator/ext2fs/large_stores.txt @@ -1,3 +1,13 @@ +[[!meta copyright="Copyright © 2005, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + This is -*- mode: outline -*- * Introduction -- cgit v1.2.3 From 8c808d2fc35892210492128eafe72cffbbc5766f Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 23 Oct 2010 23:50:00 +0200 Subject: open_issues/linux_vmsig: New. --- hurd/libpager.mdwn | 7 ++++++- open_issues/linux_vmsig.mdwn | 29 +++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+), 1 deletion(-) create mode 100644 open_issues/linux_vmsig.mdwn (limited to 'hurd') diff --git a/hurd/libpager.mdwn b/hurd/libpager.mdwn index c9a1c0b6..99f28f2a 100644 --- a/hurd/libpager.mdwn +++ b/hurd/libpager.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -14,3 +15,7 @@ Mach [[microkernel/mach/IPC]]'s [[microkernel/mach/ipc/sequence_numbering]]. [GNU Hurd Reference Manual: 4.2 Pager Library](http://www.gnu.org/software/hurd/doc/hurd_5.html#SEC32). + +# Open Issues + + * [[open_issues/linux_vmsig]] diff --git a/open_issues/linux_vmsig.mdwn b/open_issues/linux_vmsig.mdwn new file mode 100644 index 00000000..a4311d3e --- /dev/null +++ b/open_issues/linux_vmsig.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Linux: vmsig"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + + * *cooperating with the VM when memory pressure increases* + + * *notify user applications of virtual memory events via real-time signals* + +, and discussion at + and +. + +Found this via , which +was linked from [LWN](http://lwn.net/Articles/409416/). + +From a quick glance, this sounds to [[me|tschwinge]] quite a bit like +mechanisms also found in (originating in?) Mach's +[[microkernel/mach/external_pager_mechanism]]. May be worth having a look at +it. -- cgit v1.2.3 From 33809298260e49428610a2000396494d6d30cf1b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 27 Oct 2010 17:59:23 +0200 Subject: hurd/building/cross-compiling: Tag as stable_URL. Huh, this is indeed linked to from external pages. :-) --- hurd/building/cross-compiling.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'hurd') diff --git a/hurd/building/cross-compiling.mdwn b/hurd/building/cross-compiling.mdwn index 1ecfd0bd..73c19b4d 100644 --- a/hurd/building/cross-compiling.mdwn +++ b/hurd/building/cross-compiling.mdwn @@ -8,4 +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]]."]]"""]] +[[!tag stable_URL]] + [[!meta redir=/toolchain/cross-gnu]] -- cgit v1.2.3 From 11ab53a77367dc9ee6ffc70eccd31b17e610154a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 10 Nov 2010 00:10:10 +0100 Subject: hurd/running/debian/faq/sshd_only_works_for_root_logins: Issue has been fixed. --- hurd/running/debian/faq/sshd_only_works_for_root_logins.mdwn | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/running/debian/faq/sshd_only_works_for_root_logins.mdwn b/hurd/running/debian/faq/sshd_only_works_for_root_logins.mdwn index 517d59dc..1a3c46e1 100644 --- a/hurd/running/debian/faq/sshd_only_works_for_root_logins.mdwn +++ b/hurd/running/debian/faq/sshd_only_works_for_root_logins.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,6 +9,11 @@ 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 isssue has been fixed in the Debian hurd / libc0.3 packages as of 2010-11. +Retire this item sometime after 2011. + +--- + Privilege seperation does not work with Hurd currently. You need to explicitely set `PrivilegeSeparation` to `no` in `/etc/ssh/sshd_options`, just commenting out the entry will not work as it is on by default. Also make sure you have -- cgit v1.2.3 From 512f1951ca41ef1a648a3b55d2ae44da059f5415 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 14 Nov 2010 21:11:45 +0100 Subject: hurd/advantages: Rewritten some bits, and extended. --- hurd/advantages.mdwn | 99 ++++++++++++++++++++++++++-------------------------- 1 file changed, 49 insertions(+), 50 deletions(-) (limited to 'hurd') diff --git a/hurd/advantages.mdwn b/hurd/advantages.mdwn index ba3a134b..254e33f6 100644 --- a/hurd/advantages.mdwn +++ b/hurd/advantages.mdwn @@ -9,60 +9,59 @@ 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: +The GNU Hurd has a number of enticing features: + +It's free software, so anybody can use, modify, and redistribute it under the +terms of the [[GNU General Public License (GPL)|GPL]]. + +It's compatible as it provides a familiar programming and user environment. +For all intents and purposes, the Hurd provides the same facilities as 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. + +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. + +The Hurd is built in a very modular fashion. Other Unix-like kernels (Linux, +for example) are also modular in that they allow loading (and unloading) some +components as kernel modules, but the Hurd goes one step further in that most +of the components that constitute the whole kernel are running as separate +user-space processes and are thus using different address spaces that are +isolated from each other. This is a multi-server design based on a +[[microkernel]]. It is not possible that a faulty memory dereference inside +the [[TCP/IP stack|translator/pfinet]] can bring down the whole kernel, and +thus the whole system, which is a real problem in a monolothic Unix kernel +architecture. - * **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. +One advantage of the Hurd's separation of kernel-like functionality into +separate components ([[servers|translator]]) is that these can be constructed +using different programming lanugages -- a feature that is not easily possible +in a monolithic kernel. Essentially, only an interface from the programming +environment to the [[RPC]] mechanism is required. - * **it's stable** + - 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. +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 easily modified and extended. ---- +It is possible to develop and test new Hurd kernel components without rebooting +the machine. 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. -One advantage of the Hurd's separation of kernel-like functionality into -separate components ([[servers|translator]]) is that these can be constructed -using different programming lanugages, a thing that is not easily possible in a -monolithic kernel. Essentially, only an interface from the programming -environment to the RPC mechanism is required. +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|running]] and [[developing|contributing]] it. -- cgit v1.2.3 From 7cb762b6e691e22c0634f530a7054755ceb93e8f Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 14 Nov 2010 21:13:22 +0100 Subject: hurd/challenges: New. --- hurd.mdwn | 2 +- hurd/challenges.mdwn | 16 ++++++++++++++++ 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 hurd/challenges.mdwn (limited to 'hurd') diff --git a/hurd.mdwn b/hurd.mdwn index 18748229..18987760 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -29,7 +29,7 @@ in the *unstable* branch of the Debian archive. # Introduction * [[What_Is_the_GNU_Hurd]] - A Brief Description -* [[Advantages]] +* [[Advantages]]. And [[challenges]]. * [[History]] * [[history/Port_to_L4]] * [[Logo]] diff --git a/hurd/challenges.mdwn b/hurd/challenges.mdwn new file mode 100644 index 00000000..640b95c9 --- /dev/null +++ b/hurd/challenges.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + + +The GNU Hurd has a lot of [[advantages]], but there are challenges, too. + +There is no successful true multi-server [[microkernel]] system for desktop use +yet. Though, they are quite popular in the simpler embedded space. -- cgit v1.2.3 From 8ef93773281cdcaf65c83c936da0618e30a0766f Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 17 Nov 2010 17:46:21 +0100 Subject: hurd/libihash: libstdc++ stuff. --- hurd/libihash.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'hurd') diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn index 770770c7..8da04095 100644 --- a/hurd/libihash.mdwn +++ b/hurd/libihash.mdwn @@ -45,6 +45,8 @@ is included in the section entitled * NNS; cf. f46f0abfee5a2b34451708f2462a1c3b1701facd + * libstdc++: `unordered_map`, `tr1/unordered_map`, `ext/hash_map` + * * -- cgit v1.2.3 From 1e67a761cbfa94a69cec2f5709d23d7983cd0fc1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 25 Nov 2010 11:55:21 +0100 Subject: Talk about advantages, challenges, how many developers, why so few developers. --- advantages.mdwn | 71 ++++++++++++++++++ challenges.mdwn | 21 ++++++ .../gsoc/project_ideas/language_bindings.mdwn | 2 +- faq/how_many_developers.mdwn | 25 +++++++ faq/why_so_few_developers.mdwn | 27 +++++++ hurd/advantages.mdwn | 67 ----------------- hurd/challenges.mdwn | 16 ---- index.mdwn | 8 +- open_issues/benefits.mdwn | 86 --------------------- .../benefits_of_a_native_hurd_implementation.mdwn | 87 ++++++++++++++++++++++ ...implementing_hurd_on_top_of_another_system.mdwn | 45 +++++------ open_issues/multiprocessing.mdwn | 18 ++--- tag.mdwn | 5 ++ 13 files changed, 276 insertions(+), 202 deletions(-) create mode 100644 advantages.mdwn create mode 100644 challenges.mdwn create mode 100644 faq/how_many_developers.mdwn create mode 100644 faq/why_so_few_developers.mdwn delete mode 100644 hurd/advantages.mdwn delete mode 100644 hurd/challenges.mdwn delete mode 100644 open_issues/benefits.mdwn create mode 100644 open_issues/benefits_of_a_native_hurd_implementation.mdwn (limited to 'hurd') diff --git a/advantages.mdwn b/advantages.mdwn new file mode 100644 index 00000000..18e6506b --- /dev/null +++ b/advantages.mdwn @@ -0,0 +1,71 @@ +[[!meta copyright="Copyright © 2001, 2002, 2008, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The GNU Hurd has a number of enticing features: + +It's free software, so anybody can use, modify, and redistribute it under the +terms of the [[GNU General Public License (GPL)|GPL]]. + +It's compatible as it provides a familiar programming and user environment. +For all intents and purposes, the Hurd provides the same facilities as 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. + +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. + +The Hurd is built in a very modular fashion. Other Unix-like kernels (Linux, +for example) are also modular in that they allow loading (and unloading) some +components as kernel modules, but the Hurd goes one step further in that most +of the components that constitute the whole kernel are running as separate +user-space processes and are thus using different address spaces that are +isolated from each other. This is a multi-server design based on a +[[microkernel]]. It is not possible that a faulty memory dereference inside +the [[TCP/IP stack|hurd/translator/pfinet]] can bring down the whole kernel, +and thus the whole system, which is a real problem in a monolothic Unix kernel +architecture. + +One advantage of the Hurd's separation of kernel-like functionality into +separate components ([[servers|hurd/translator]]) is that these can be +constructed using different programming lanugages -- a feature that is not +easily possible in a monolithic kernel. Essentially, only an interface from +the programming environment to the [[RPC]] mechanism is required. (We have a +[[project proposal|community/gsoc/project_ideas/language_bindings]] for this, +if you're interested.) + + + +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 easily modified and extended. + +It is possible to develop and test new Hurd kernel components without rebooting +the machine. 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. + +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|hurd/running]] and [[developing|contributing]] it. + + diff --git a/challenges.mdwn b/challenges.mdwn new file mode 100644 index 00000000..5368ae4e --- /dev/null +++ b/challenges.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The GNU Hurd has a lot of [[advantages]], but there are challenges, too. + +Even though they're quite popular in the simpler embedded space, there is no +successful true multi-server [[microkernel]] system for general-purpose desktop +use yet. This is still an ongoing research effort. (TODO: add references.) + +Likewise, resource scheduling in distributed operating system kernels is a +research topic. For example, read more about it on the relevant [[Open Issues +page|open_issues/multiprocessing]]. + +TODO: more to come. [[!tag open_issue_documentation]] diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn index 460b380b..c8a02390 100644 --- a/community/gsoc/project_ideas/language_bindings.mdwn +++ b/community/gsoc/project_ideas/language_bindings.mdwn @@ -20,7 +20,7 @@ However, in practice this is not as easy as it should, because creating translators and other servers is quite involved -- the interfaces for doing that are not exactly simple, and available only for C programs. Being able to easily create simple translators in RAD languages is highly desirable, to -really be able to reap the advantages of the Hurd architecture. +really be able to reap the [[advantages]] of the Hurd architecture. Originally Lisp was meant to be the second system language besides C in the GNU system; but that doesn't mean we are bound to Lisp. Bindings for any popular diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn new file mode 100644 index 00000000..a553df21 --- /dev/null +++ b/faq/how_many_developers.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="How many developers are working on the GNU Hurd?"]] + +Not many. One handful work on it in their free time, and another two +handful do help with [[Debian GNU/Hurd|hurd/running/debian]] and +[[hurd/running/Arch_Hurd]] packaging. Also, an additional handful of +former developers are still availble for answering technical questions, +but are not really participating in the current development anymore. + +For reaching out to new developers, we're participating in [[Google's +Summer of Code program|community/gsoc]]. Likewise, any interested party +(*you*!) are very welcome to start [[contributing]]. Mentoring is +possible, too, to help you get started. + +Continue reading some speculation about [[why so few developers]] are working +on the GNU Hurd. diff --git a/faq/why_so_few_developers.mdwn b/faq/why_so_few_developers.mdwn new file mode 100644 index 00000000..a2740abc --- /dev/null +++ b/faq/why_so_few_developers.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Why are there so few developers working on the GNU +Hurd?"]] + +[[There aren't working a lot of people on the GNU +Hurd|how_many_developers]]. Why is this? + +We can only speculate. One major problem might be that the +[[architectural benefits|advantages]] are generally perceived as very +abstract, with little practical benefits. We don't have many tools to +present actually making use of the possibilities. + +Another reason is that it's been taking too long. Most people don't +believe it will ever be ready for production use, and thus would consider +involvement a waste of time. This latter point is invalid, of course, as +learning can never be a waste of time. The same holds for the +[[challenges]] raised by the GNU Hurd -- we can only learn and improve +upon working on them. diff --git a/hurd/advantages.mdwn b/hurd/advantages.mdwn deleted file mode 100644 index 254e33f6..00000000 --- a/hurd/advantages.mdwn +++ /dev/null @@ -1,67 +0,0 @@ -[[!meta copyright="Copyright © 2001, 2002, 2008, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -The GNU Hurd has a number of enticing features: - -It's free software, so anybody can use, modify, and redistribute it under the -terms of the [[GNU General Public License (GPL)|GPL]]. - -It's compatible as it provides a familiar programming and user environment. -For all intents and purposes, the Hurd provides the same facilities as 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. - -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. - -The Hurd is built in a very modular fashion. Other Unix-like kernels (Linux, -for example) are also modular in that they allow loading (and unloading) some -components as kernel modules, but the Hurd goes one step further in that most -of the components that constitute the whole kernel are running as separate -user-space processes and are thus using different address spaces that are -isolated from each other. This is a multi-server design based on a -[[microkernel]]. It is not possible that a faulty memory dereference inside -the [[TCP/IP stack|translator/pfinet]] can bring down the whole kernel, and -thus the whole system, which is a real problem in a monolothic Unix kernel -architecture. - -One advantage of the Hurd's separation of kernel-like functionality into -separate components ([[servers|translator]]) is that these can be constructed -using different programming lanugages -- a feature that is not easily possible -in a monolithic kernel. Essentially, only an interface from the programming -environment to the [[RPC]] mechanism is required. - - - -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 easily modified and extended. - -It is possible to develop and test new Hurd kernel components without rebooting -the machine. 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. - -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|running]] and [[developing|contributing]] it. diff --git a/hurd/challenges.mdwn b/hurd/challenges.mdwn deleted file mode 100644 index 640b95c9..00000000 --- a/hurd/challenges.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - - - -The GNU Hurd has a lot of [[advantages]], but there are challenges, too. - -There is no successful true multi-server [[microkernel]] system for desktop use -yet. Though, they are quite popular in the simpler embedded space. diff --git a/index.mdwn b/index.mdwn index 249b2091..9520a438 100644 --- a/index.mdwn +++ b/index.mdwn @@ -31,7 +31,7 @@ computing environment as possible. --- -[[!toc]] +[[!toc levels=2]] ## News @@ -122,6 +122,12 @@ For more details, please read our writeup on the [[current_state_of_the_GNU_Hurd|hurd/status]]. +### Advantages and Challenges + +The GNU Hurd operating system design provides [[advantages]], but uncovers new +[[challenges]], too. + + ## How is this site arranged? The menu on the upper right corner provides a rough structuring about the diff --git a/open_issues/benefits.mdwn b/open_issues/benefits.mdwn deleted file mode 100644 index da1248c8..00000000 --- a/open_issues/benefits.mdwn +++ /dev/null @@ -1,86 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -[[!tag open_issue_documentation]] - -What are the benefits of a native GNU/Hurd system, now that Linux et al. can do -so much (think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux, -etc.). - -It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but... - -IRC, #hurd, August / September 2010 - - ArneBab: but Neal and I were not happy with that alone. We were - looking for deeper improvements to the system, for, I think, sound reasons. - That is what brought us to the L4/Coyotos technologies - ArneBab: as you are writing a kernel in user space, you can still do - kernel improvements there - ArneBab: if you take it very far, you end up with a kernel that runs - Linux in user space (just flip the two) for the drivers - ArneBab: that is what the L4 people did with the DDE - -([[DDE]]) - - ArneBab: so, with these different cuts, there are different - opportunities. on the one end, you can run Linux as normal and get some of - the Hurd features such as translators in some programs. At the other end, - you can do whatever you want and run some linux code for the drivers or none - at all. - ArneBab: one of the big questions then becomes: at which point can - the advantages offered by the Hurd be realized? - ArneBab: and that's not entirely clear to me - when I worked on this with Neal, we pushed further and further into - need-to-change-everything land - while the current efforts on the Hurd seem to be more equivalent to - the could-run-it-in-userspace-on-top-of-Linux camp - marcusb: for that I think we need a way to move towards them step by - step. Would it be possible to get the advantages of better resource - allocation with a Viengoos in userspace, too? - and when that is stable, just switch over? - ArneBab: I don't know. I suspect these people will know before us: - http://lxc.sourceforge.net/ - something like implementing flip points: flip Linux with Hurd to Hund - with Linux. Flip Mach with L4 to L4 with Mach. - lxc sounds interesting. - note that these efforts address security concerns more than other - concerns - so they will get isolation long before sharing is even considered - but some of the issues are the same - once you allow malware to do what it wants, it's a small step to also - allow the user to what he wants :) - it kinda looks like hacking it where it doesn’t really fit again… - there I ask myself when the point comes that doing a cleaner design - offsets the popularity - they are pushing more and more stuff into userspace - which is a good thing (to me) - it’s hard to clearly describe how, but even though I like having more - stuff in userspace, the way it is bolted onto Linux doesn’t feel good for me. - FUSE is cool, but if I use it, I am at a disadvantage compared to a - non-fuse user - while in the Hurd, these additional options are on eqal footing. - ArneBab: are they pushing more and more into user space? I don't - think so. I see more of the reverse, actually - or maybe both - FUSE, lxd and scheduling in userspace move to userspace - well, KMS moved to the kernel - to avoid flickering when switching between X and the console? - marcusb: Do you experience FUSE lxc and such being secondclass in - Linux, too, or is that just a strange feeling of me? - marcusb: and that splits the users into those who can get stuff into - the kernel and those who can only work in userspace – which I don’t really - like. - That’s one more advantage of the Hurd: eqal footing for all (except - the Mach hackers, but they have a very limited terrain) - ArneBab: but UML kernel module is minimal, and Linus didn't have a - principled objection to it (but just wanted a more general solution) - ArneBab: as a side note, although people keep complaining, the linux - kernel seems to be growing steadily, so getting stuff into the kernel doesn't - seem too hard. 8-O diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn new file mode 100644 index 00000000..34e49e86 --- /dev/null +++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn @@ -0,0 +1,87 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +What are the benefits of a native GNU/Hurd system, now that Linux et al. can do +so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux +and other virtualization techiques, and so on. + +It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but... + +IRC, #hurd, August / September 2010 + + ArneBab: but Neal and I were not happy with that alone. We were + looking for deeper improvements to the system, for, I think, sound + reasons. That is what brought us to the L4/Coyotos technologies + ArneBab: as you are writing a kernel in user space, you can still + do kernel improvements there + ArneBab: if you take it very far, you end up with a kernel that + runs Linux in user space (just flip the two) for the drivers + ArneBab: that is what the L4 people did with the DDE + +([[DDE]]) + + ArneBab: so, with these different cuts, there are different + opportunities. on the one end, you can run Linux as normal and get some + of the Hurd features such as translators in some programs. At the other + end, you can do whatever you want and run some linux code for the drivers + or none at all. + ArneBab: one of the big questions then becomes: at which point + can the advantages offered by the Hurd be realized? + ArneBab: and that's not entirely clear to me + when I worked on this with Neal, we pushed further and further + into need-to-change-everything land + while the current efforts on the Hurd seem to be more equivalent + to the could-run-it-in-userspace-on-top-of-Linux camp + marcusb: for that I think we need a way to move towards them step + by step. Would it be possible to get the advantages of better resource + allocation with a Viengoos in userspace, too? + and when that is stable, just switch over? + ArneBab: I don't know. I suspect these people will know before + us: http://lxc.sourceforge.net/ + something like implementing flip points: flip Linux with Hurd to + Hund with Linux. Flip Mach with L4 to L4 with Mach. + lxc sounds interesting. + note that these efforts address security concerns more than other + concerns + so they will get isolation long before sharing is even considered + but some of the issues are the same + once you allow malware to do what it wants, it's a small step to + also allow the user to what he wants :) + it kinda looks like hacking it where it doesn’t really fit again… + there I ask myself when the point comes that doing a cleaner + design offsets the popularity + they are pushing more and more stuff into userspace + which is a good thing (to me) + it’s hard to clearly describe how, but even though I like having + more stuff in userspace, the way it is bolted onto Linux doesn’t feel + good for me. + FUSE is cool, but if I use it, I am at a disadvantage compared to + a non-fuse user + while in the Hurd, these additional options are on eqal footing. + ArneBab: are they pushing more and more into user space? I don't + think so. I see more of the reverse, actually + or maybe both + FUSE, lxd and scheduling in userspace move to userspace + well, KMS moved to the kernel + to avoid flickering when switching between X and the console? + marcusb: Do you experience FUSE lxc and such being secondclass in + Linux, too, or is that just a strange feeling of me? + marcusb: and that splits the users into those who can get stuff + into the kernel and those who can only work in userspace – which I don’t + really like. + That’s one more advantage of the Hurd: eqal footing for all + (except the Mach hackers, but they have a very limited terrain) + ArneBab: but UML kernel module is minimal, and Linus didn't have + a principled objection to it (but just wanted a more general solution) + ArneBab: as a side note, although people keep complaining, the + linux kernel seems to be growing steadily, so getting stuff into the + kernel doesn't seem too hard. 8-O diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn index 1d7a1e50..7e88e322 100644 --- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn +++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn @@ -21,8 +21,8 @@ IRC, #hurd, August / September 2010 silver_hook: the Hurd can also refer to the interfaces of the filesystems etc, and a lot of that is really just server/client APIs that - could be implemented on any system that has transferable rights to message - capabilities. + could be implemented on any system that has transferable rights to + message capabilities. silver_hook: it's surprising how few systems *have* transferable rights, though! silver_hook: usually it is added as an afterthought @@ -33,23 +33,24 @@ IRC, #hurd, August / September 2010 youpi: it's described in the Stevens series even [...] ArneBab: well, let me put it this way. the Linux kernel has no - interface to manipulate another tasks's virtual address space, ie you can't - map/unmap stuff in another process - ArneBab: you would have to use ptrace and load some stub code in that - process to make that happen. - ArneBab: so for complete transparent manipulation, you need a kernel - module + interface to manipulate another tasks's virtual address space, ie you + can't map/unmap stuff in another process + ArneBab: you would have to use ptrace and load some stub code in + that process to make that happen. + ArneBab: so for complete transparent manipulation, you need a + kernel module that is what the User Mode Linux kernel module does - ArneBab: so say you use the User Mode Linux kernel module for that - one feature. Then you can do everything that User Mode Linux can do, which, - I assure you, includes running subhurds :) + ArneBab: so say you use the User Mode Linux kernel module for + that one feature. Then you can do everything that User Mode Linux can + do, which, I assure you, includes running subhurds :) it can be a bit tricky to implement those features, but it is not harder than writing a kernel in the first place - So, if I got an admin to install User Mode Linux and Mach emulation, - I’d get the flexibility (and independence from admin decisions) I have in the - Hurd? - ArneBab: one problem is that you still use Linux. For those who want - to get rid of Linux for political reasons, that would mean complete failure + So, if I got an admin to install User Mode Linux and Mach + emulation, I’d get the flexibility (and independence from admin + decisions) I have in the Hurd? + ArneBab: one problem is that you still use Linux. For those who + want to get rid of Linux for political reasons, that would mean complete + failure ArneBab: if you have UML kernel module, you can implement Mach in user space ArneBab: in fact, John Tobey did this a couple of years ago, or @@ -57,10 +58,10 @@ IRC, #hurd, August / September 2010 ([[tschwinge]] has tarballs of John's work.) - ArneBab: or you can just implement parts of it and relay to Linux for - the rest - the point is, that if you don't care for kernel improvements, and are - sufficiently happy with the translator stuff, it's not hard to bring the Hurd - to Linux or BSD + ArneBab: or you can just implement parts of it and relay to Linux + for the rest + the point is, that if you don't care for kernel improvements, and + are sufficiently happy with the translator stuff, it's not hard to bring + the Hurd to Linux or BSD -(Continue: [[benefits]].) +Continue reading about the [[benefits of a native Hurd implementation]]. diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn index 7b4f2611..224c0826 100644 --- a/open_issues/multiprocessing.mdwn +++ b/open_issues/multiprocessing.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] We would expect that fine-grained, compartmentalized systems, that is, -microkernel-based multi-server systems in particular, would be ideal condidates +microkernel-based multi-server systems in particular, would be ideal candidates for applying multiprocessing. That is, however, only true from a first and inexperienced point of view: there are many difficulties. @@ -19,14 +19,14 @@ inexperienced point of view: there are many difficulties. IRC, #hurd, August / September 2010 silver_hook: because multi-server systems depend on inter-process - communication, and inter-process communication is many times more expensive - across cpus - silver_hook: so you either force interrelated work on the same cpu, - or suffer heavy penalties. and in a typical fine-grained object system, all - objects are interconnected! - silver_hook: resources in today's systems, even in a single node with - one cpu, but more so in a network, are very non-uniform. scheduling these - resources efficiently is a huge problem. restricting the resource + communication, and inter-process communication is many times more + expensive across cpus + silver_hook: so you either force interrelated work on the same + cpu, or suffer heavy penalties. and in a typical fine-grained object + system, all objects are interconnected! + silver_hook: resources in today's systems, even in a single node + with one cpu, but more so in a network, are very non-uniform. scheduling + these resources efficiently is a huge problem. restricting the resource distribution policies in the way microkernel systems tend to do is posing serious research challenges diff --git a/tag.mdwn b/tag.mdwn index e96e88d5..6051de3b 100644 --- a/tag.mdwn +++ b/tag.mdwn @@ -23,6 +23,11 @@ Most of them should be self-explanatory. GNU/Hurd|hurd/running/debian]] distribution, but not yet in the upstream sources. + * *open_issue_documentation* + + Use for tagging pages / items that need to be handled / improved for + documentation purposes. + * *open_issue_porting* A list of open issues in porting software to run on GNU/Hurd systems. This -- cgit v1.2.3 From e36d3838db972fedfed4a30968ed144a9f0f6c96 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 27 Nov 2010 21:47:25 +0100 Subject: hurd/io_path: Link to Linux kernel design patterns - part 3 (2009-06-22) by Neil Brown. --- hurd/io_path.mdwn | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) (limited to 'hurd') diff --git a/hurd/io_path.mdwn b/hurd/io_path.mdwn index 78e13efd..598ad967 100644 --- a/hurd/io_path.mdwn +++ b/hurd/io_path.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="I/O Path"]] + # read @@ -38,3 +41,12 @@ is included in the section entitled * ext2fs eventually finishes the data_request() function, the kernel installs the page into the process that got a fault. + + +# Documentation + + * In [*Linux kernel design patterns - part + 3*](http://lwn.net/Articles/336262/) (2009-06-22), Neil Brown gives a + nice overview of the related layering inside the Linux kernel, + including the VFS layer, page cache and directory entry cache + (dcache). -- cgit v1.2.3 From d05a838d0fc7037f4a99a97742680a68b8b157d8 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 27 Nov 2010 21:53:21 +0100 Subject: hurd/libchannel: Link to Van Jacobson's network channels (2006-01-31) by Jonathan Corbet. --- hurd/libchannel.mdwn | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) (limited to 'hurd') diff --git a/hurd/libchannel.mdwn b/hurd/libchannel.mdwn index 91c7810f..3e19fb18 100644 --- a/hurd/libchannel.mdwn +++ b/hurd/libchannel.mdwn @@ -1,12 +1,12 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] # libchannel @@ -60,3 +60,9 @@ library to implement specialized channel libraries, e.g. *libaudio* and *libnetwork* or similar. So work on *libchannel* will continue, in one form or another. + + +# Related + + * [*Van Jacobson's network channels*](http://lwn.net/Articles/169961/) + (2006-01-31) by Jonathan Corbet. -- cgit v1.2.3 From eccf2986513cc41c412b1c30aa5dcb88a4c981b5 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 29 Nov 2010 07:58:51 +0100 Subject: Add links to some LWN articles, and then some. --- community/gsoc/project_ideas.mdwn | 6 +-- .../gsoc/project_ideas/libdiskfs_locking.mdwn | 41 ----------------- documentation.mdwn | 6 ++- glibc.mdwn | 9 ++++ glibc/environment_variables.mdwn | 15 ++++++ glibc/fork.mdwn | 9 ++++ glibc/poll.mdwn | 15 ++++++ hurd/debugging.mdwn | 10 ++-- hurd/translator.mdwn | 6 ++- hurd/translator/libguestfs.mdwn | 15 ++++++ open_issues/debugging.mdwn | 42 +++++++++++++++++ open_issues/gdb-heap.mdwn | 15 ++++++ open_issues/locking.mdwn | 53 ++++++++++++++++++++++ open_issues/performance.mdwn | 2 + open_issues/unit_testing.mdwn | 10 ++++ open_issues/virtualization/file_systems.mdwn | 3 +- unix.mdwn | 16 +++++-- 17 files changed, 214 insertions(+), 59 deletions(-) delete mode 100644 community/gsoc/project_ideas/libdiskfs_locking.mdwn create mode 100644 glibc/environment_variables.mdwn create mode 100644 glibc/poll.mdwn create mode 100644 hurd/translator/libguestfs.mdwn create mode 100644 open_issues/debugging.mdwn create mode 100644 open_issues/gdb-heap.mdwn create mode 100644 open_issues/locking.mdwn (limited to 'hurd') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 2102e8f7..b039608f 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] We offer a wide range of possible projects to choose from. If you have an idea not listed here, we'd love to hear about it! @@ -82,7 +82,7 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]] +[[!inline pages="open_issues/locking" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/pthreads" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]] [[!inline pages="open_issues/performance/io_system" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn deleted file mode 100644 index 0618bbe6..00000000 --- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -[[!meta title="Fix libdiskfs Locking Issues"]] - -Nowadays the most often encountered cause of Hurd crashes seems to be lockups -in the [[hurd/translator/ext2fs]] server. One of these could be traced -recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken -and not released in some cases. There is reason to believe that there are more -faulty paths causing these lockups. - -The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking -issues. To achieve this, some kind of test harness has to be implemented: For -example instrumenting the code to check locking correctness constantly at -runtime. Or implementing a unit testing framework that explicitly checks -locking in various code paths. (The latter could serve as a template for -implementing unit checks in other parts of the Hurd codebase...) - -(A systematic code review would probably suffice to find the existing locking -issues; but it wouldn't document the work in terms of actual code produced, and -thus it's not suitable for a GSoC project...) - -[Linux' *sparse*](https://sparse.wiki.kernel.org/) could be worth looking at. - -This task requires experience with debugging locking issues in multithreaded -applications. - -Possible mentors: Samuel Thibault (youpi) - -Exercise: If you could actually track down and fix one of the existing locking -errors before the end of the application process, that would be excellent. This -might be rather tough though, so probably you need to talk to us about an -alternative exercise task... diff --git a/documentation.mdwn b/documentation.mdwn index 62d96e9c..5c666f3f 100644 --- a/documentation.mdwn +++ b/documentation.mdwn @@ -5,8 +5,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[FAQ]] @@ -18,6 +18,8 @@ Documentation for... * [[MIG|microkernel/mach/mig/documentation]] + * [[UNIX]] + # Presentations diff --git a/glibc.mdwn b/glibc.mdwn index cefbb19c..f47efc03 100644 --- a/glibc.mdwn +++ b/glibc.mdwn @@ -29,6 +29,15 @@ Porting glibc to a specific architecture is non-trivial. ## [[Hurd-specific Port|hurd/glibc]] +# Implementation Details + + * [[environment_variables]] + + * [[fork]] + + * [[poll]] + + # Open Issues [[!inline pages=tag/open_issue_glibc raw=yes feeds=no]] diff --git a/glibc/environment_variables.mdwn b/glibc/environment_variables.mdwn new file mode 100644 index 00000000..76c1371e --- /dev/null +++ b/glibc/environment_variables.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +# External + + * [*putenv() and setenv()*](http://www.greenend.org.uk/rjk/2008/putenv.html) + by Richard Kettlewell. diff --git a/glibc/fork.mdwn b/glibc/fork.mdwn index 564d9d5b..c9efd1f4 100644 --- a/glibc/fork.mdwn +++ b/glibc/fork.mdwn @@ -49,3 +49,12 @@ they have patches for software packages, to avoid using `fork` followed by * We no longer support `MACH_IPC_COMPAT`, thus we can get rid of the `err = __mach_port_allocate_name ([...]); if (err == KERN_NAME_EXISTS)` code ([[!taglink open_issue_glibc]]). + + +# External + + * [*How fork(2) ought to be*](http://www.greenend.org.uk/rjk/fork.html) by + Richard Kettlewell. + + * [*The self-pipe trick*](http://cr.yp.to/docs/selfpipe.html) by + D. J. Bernstein. diff --git a/glibc/poll.mdwn b/glibc/poll.mdwn new file mode 100644 index 00000000..d96f27a5 --- /dev/null +++ b/glibc/poll.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +# External + + * [*poll() and EOF*](http://www.greenend.org.uk/rjk/2001/06/poll.html) by + Richard Kettlewell. diff --git a/hurd/debugging.mdwn b/hurd/debugging.mdwn index d6c5b18f..d6e9c8b5 100644 --- a/hurd/debugging.mdwn +++ b/hurd/debugging.mdwn @@ -6,8 +6,9 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + # Strategies @@ -16,11 +17,6 @@ is included in the section entitled * [[subhurd]] -- running another Hurd system in parallel * [[rpctrace]] -- tracing [[RPC]]s -## To Do - - * [[open_issues/ltrace]] - * [[open_issues/latrace]] - * [[open_issues/profiling]] # About Specific Packages diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index c3ca1278..9e109a28 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A translator is simply a normal program acting as an object server and participating in the Hurd's @@ -117,6 +117,8 @@ Read about translator [[short-circuiting]]. * [[wishlist_1]] * [[wishlist_2]] * [[open_issues/network_file_system_by_just_forwarding_RPCs]] + * [[libguestfs]] + # Internally diff --git a/hurd/translator/libguestfs.mdwn b/hurd/translator/libguestfs.mdwn new file mode 100644 index 00000000..649b31f5 --- /dev/null +++ b/hurd/translator/libguestfs.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +[libguestfs](http://libguestfs.org/) is said to be able to access a lot +of different filesystem types -- can we use it to build GNU Hurd +[[translator]]s? (There is a [[FUSE]] module, too.) diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn new file mode 100644 index 00000000..95b7bf9b --- /dev/null +++ b/open_issues/debugging.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +# Existing + +We have debugging infrastructure. For example: + + * [[GDB]] + + * [[GNU Mach debugging|microkernel/mach/gnumach/debugging]] + + * [[GNU Hurd debugging|hurd/debugging]], including + [[hurd/debugging/rpctrace]] and more. + + +# To Do + + * [[ltrace]] + + * [[latrace]] + + * [[profiling]] + + * *[Checkpoint/restart](http://lwn.net/Articles/412749/) allows the state of + a set of processes to be saved to persistent storage, then restarted at + some future time* -- quoting from Jonathan Corbet's 2010 Linux Kernel + Summit report. + + This is surely a very useful facility to have for reproducing failures, for + example. But on the other hand it's questionable how it can help with + debugging failures in [[GNU Hurd server|hurd/translator]]s' interactions, + as their state is typically spread between several processes. + + * [[locking]] diff --git a/open_issues/gdb-heap.mdwn b/open_issues/gdb-heap.mdwn new file mode 100644 index 00000000..75c31bbe --- /dev/null +++ b/open_issues/gdb-heap.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb]] + +Might be interesting to have a look at +[*gdb-heap*](https://fedorahosted.org/gdb-heap/) with respect to our +long-lived [[hurd/translator]] processes. diff --git a/open_issues/locking.mdwn b/open_issues/locking.mdwn new file mode 100644 index 00000000..1717133a --- /dev/null +++ b/open_issues/locking.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +Every now and then, new locking issues are discovered in +[[hurd/libdiskfs]] or [[hurd/translator/ext2fs]], for example. Nowadays +these in fact seem to be the most often encountered cause of Hurd crashes +/ lockups. + +One of these could be traced +recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken +and not released in some cases. There is reason to believe that there are more +faulty paths causing these lockups. + +The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking +issues. To achieve this, some kind of test harness has to be implemented: For +example instrumenting the code to check locking correctness constantly at +runtime. Or implementing a [[unit testing]] framework that explicitly checks +locking in various code paths. (The latter could serve as a template for +implementing unit tests in other parts of the Hurd codebase...) + +(A systematic code review would probably suffice to find the existing locking +issues; but it wouldn't document the work in terms of actual code produced, and +thus it's not suitable for a GSoC project...) + +This task requires experience with debugging locking issues in multithreaded +applications. + +Tools have been written for static code analysis, than can help to locate +and fix such errors. + + * Coccinelle + + * + + * + + * clang + + * + + * Linux' sparse + + * diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index a4816680..3d146a72 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.mdwn @@ -11,3 +11,5 @@ License|/fdl]]."]]"""]] * [[I/O System|io_system]] * [[fork]] + + * [[unit testing]] diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn index b9fb3700..80a2860a 100644 --- a/open_issues/unit_testing.mdwn +++ b/open_issues/unit_testing.mdwn @@ -43,3 +43,13 @@ abandoned). * * + + * [*[ANNOUNCE] ktest.pl: Easy and flexible testing script for Linux Kernel + Developers*](http://lwn.net/Articles/412302/) by Steven Rostedt, + 2010-10-28. + + * -- ``comprehensive testing and + benchmarking platform''. This one might be useful for [[performance]] + testing, too? + + * diff --git a/open_issues/virtualization/file_systems.mdwn b/open_issues/virtualization/file_systems.mdwn index 3bf2299d..a12ea10d 100644 --- a/open_issues/virtualization/file_systems.mdwn +++ b/open_issues/virtualization/file_systems.mdwn @@ -20,4 +20,5 @@ be explored. * Linux saw a patch for [*generic name to handle and open by handle syscalls*](http://thread.gmane.org/gmane.linux.file-systems/46648) posted, which in turn can be beneficial for a [[QEMU]] emulation of a 9P file - system. + system. LWN's Jonathan Corbet covered this [*open by + handle*](http://lwn.net/Articles/375888/) functionality on 2010-02-23. diff --git a/unix.mdwn b/unix.mdwn index a927eb64..601b36d1 100644 --- a/unix.mdwn +++ b/unix.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="UNIX"]] + # External @@ -15,3 +18,10 @@ is included in the section entitled * [*Standardizing UNIX*](http://www.informit.com/articles/printerfriendly.aspx?p=691503), an article by David Chisnall. + + * [*Ghosts of Unix Past: a historical search for design + patterns*](http://lwn.net/Articles/411845/) (2010-10-27) by Neil Brown, + including file descriptors and the single, hierarchical namespace. + + * [*UNIX File Permissions*](http://www.greenend.org.uk/rjk/2004/perms.html) + (2004) by Richard Kettlewell. -- cgit v1.2.3 From 38368072b37bf73dda26dac536e4aa6cf13c67e4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 29 Nov 2010 13:41:16 +0100 Subject: system_call: New. --- community/gsoc/project_ideas/libcap.mdwn | 8 ++++---- community/gsoc/project_ideas/libcap/details.mdwn | 8 ++++---- community/gsoc/project_ideas/secure_chroot.mdwn | 11 ++++++----- community/gsoc/project_ideas/valgrind.mdwn | 8 ++++---- extensibility.mdwn | 9 +++++---- faq/sharing_the_user_space.mdwn | 2 +- glibc.mdwn | 13 +++++++++++-- glibc/fork.mdwn | 20 +++++++++++++------- hurd/glibc/hurd-specific_api.mdwn | 11 ++++++----- hurd/networking.mdwn | 11 ++++++----- hurd/ng/microkernelcoyotos.mdwn | 4 +++- hurd/ng/trivialconfinementvsconstructorvsfork.mdwn | 18 ++++++++++++++---- hurd/translator/wishlist_2.mdwn | 12 +++++++++++- qemu.mdwn | 12 ++++++------ system_call.mdwn | 19 +++++++++++++++++++ 15 files changed, 113 insertions(+), 53 deletions(-) create mode 100644 system_call.mdwn (limited to 'hurd') diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn index 1346203d..18c49c48 100644 --- a/community/gsoc/project_ideas/libcap.mdwn +++ b/community/gsoc/project_ideas/libcap.mdwn @@ -1,12 +1,12 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Implementing libcap"]] @@ -33,7 +33,7 @@ probably doable without previous experience with either, though. David Hedberg applied for this project in 2010, and though he didn't go through with it, -he fleshed out many [[libcap/details]]. +he fleshed out many [[details]]. Possible mentors: Samuel Thibault (youpi) diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn index aa27a84e..85695978 100644 --- a/community/gsoc/project_ideas/libcap/details.mdwn +++ b/community/gsoc/project_ideas/libcap/details.mdwn @@ -5,8 +5,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Details on implementing libcap"]] @@ -59,7 +59,7 @@ Each process has a three bit fields representing each of the three sets (P, E and I). Each bit field is currently built up of two (32 bit) integers to be able to hold the 33 currently defined capabilities (see linux/capability.h). Each process further has a bounding set which -bounds the permitted set. Two syscalls handles the setting and getting +bounds the permitted set. Two [[system call]]s handles the setting and getting of capabilities; *capset* and *capget*. Some related functionality can also be controlled by calling *prctl*: the right to read/drop the bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether @@ -428,7 +428,7 @@ the following (also detailed somewhat in the same article): * Execute process as root (or setuid) to gain all capabilities. -* Use the prctl system call to enable keepcaps for the process +* Use the prctl [[system call]] to enable keepcaps for the process (same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process). keepcaps should be off by default. diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn index feb30a7c..57739861 100644 --- a/community/gsoc/project_ideas/secure_chroot.mdwn +++ b/community/gsoc/project_ideas/secure_chroot.mdwn @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Secure chroot Implementation"]] As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a -`chroot()` system call. However, the current implementation is not really +`chroot` [[system call]]. However, the current implementation is not really good, as it allows easily escaping the `chroot`, for example by use of [[passive_translators|hurd/translator]]. @@ -20,7 +21,7 @@ workaround changing the behavior of passive translators in a `chroot`; changing the context in which passive translators are executed; changing the interpretation of filenames in a chroot; to reworking the whole passive translator mechanism. Some involving a completely different approach to -`chroot` implementation, using a proxy instead of a special system call in the +`chroot` implementation, using a proxy instead of a special [[system call]] in the filesystem servers. See diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn index c6fc7459..7d68e82d 100644 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ b/community/gsoc/project_ideas/valgrind.mdwn @@ -18,7 +18,7 @@ although they work on Linux. Even more importantly, it will help finding bugs in the Hurd servers themselfs. To keep track of memory use, -Valgrind however needs to know how each system call affects the validity of memory regions. +Valgrind however needs to know how each [[system call]] affects the validity of memory regions. This knowledge is highly kernel-specific, and thus Valgrind needs to be explicitely ported for every system. @@ -26,11 +26,11 @@ Such a port involves two major steps: making Valgrind understand how kernel traps work in general on the system in question; and how all the individual kernel calls affect memory. The latter step is where most of the work is, -as the behaviour of each single system call needs to be described. +as the behaviour of each single [[system call]] needs to be described. Compared to Linux, Mach (the microkernel used by the Hurd) has very few kernel traps. -Almost all system calls are implemented as RPCs instead -- +Almost all [[system call]]s are implemented as RPCs instead -- either handled by Mach itself, or by the various Hurd servers. All RPCs use a pair of mach\_msg() invocations: one to send a request message, and one to receive a reply. @@ -62,7 +62,7 @@ The goal of this task is at minimum to make Valgrind grok Mach traps, and to implement the generic RPC handler. Ideally, specific handling for RPCs needing it should also be implemented. -Completing this project will require digging into Valgrind's handling of system calls, +Completing this project will require digging into Valgrind's handling of [[system call]]s, and into Hurd RPCs. It is not an easy task, but a fairly predictable one -- there shouldn't be any unexpected difficulties, diff --git a/extensibility.mdwn b/extensibility.mdwn index 01b1f3b1..17cd5e51 100644 --- a/extensibility.mdwn +++ b/extensibility.mdwn @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] An extensible system is one that enables extensibility. Enabling extensibility means providing non-privileged mechanisms to extend existing objects and to introduce new objects. [[UNIX]] is generally not an extensible system as it does -not generally facilitate the hooking of system calls. For instance, there is +not generally facilitate the hooking of [[system call]]s. For instance, there is no way to hook into the virtual file system. This has motivated the introduction of separate, parallel interfaces by both the GNOME and KDE projects to provide users a more integrated view of their objects. diff --git a/faq/sharing_the_user_space.mdwn b/faq/sharing_the_user_space.mdwn index 7d09ccc0..ec880827 100644 --- a/faq/sharing_the_user_space.mdwn +++ b/faq/sharing_the_user_space.mdwn @@ -15,7 +15,7 @@ everything but the kernel is shared? *Answer:* Given that both Linux and GNU Hurd are using the [[ELF]] binary format, this could indeed be made possible, if all programs agreed to rely on only one abstraction layer, for example the standard C library ([[glibc]]). -(Additionally, for example for system calls that are not covered by glibc +(Additionally, for example for [[system call]]s that are not covered by glibc calls, you'd need to be able to reliably trap and emulate these.) However, Linux' and the GNU Hurd's [[ABI]]'s have sufficiently diverged, so that this is not easy to do. That's why you can't currently install a system in this way, diff --git a/glibc.mdwn b/glibc.mdwn index f47efc03..2eba3667 100644 --- a/glibc.mdwn +++ b/glibc.mdwn @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="GNU C Library"]] @@ -31,6 +31,15 @@ Porting glibc to a specific architecture is non-trivial. # Implementation Details + * [[hurd/glibc/Hurd-specific API]] + + * [[open_issues/secure_file_descriptor_handling]] + + +## Individual functions + +Some of these are well-known as [[UNIX]] [[system call]]s. + * [[environment_variables]] * [[fork]] diff --git a/glibc/fork.mdwn b/glibc/fork.mdwn index c9efd1f4..e8556a91 100644 --- a/glibc/fork.mdwn +++ b/glibc/fork.mdwn @@ -8,7 +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]]."]]"""]] -On [[Unix]] systems, `fork` is a rather simple system call. +On [[Unix]] systems, `fork` is a rather simple [[system call]]. Our implementation in [[glibc]] is and needs to be rather bulky. @@ -22,12 +22,13 @@ which requires a small number of [[RPC]] for each of them. In sum, [[this affects performance|open_issues/performance/fork]] when new processes are continuously being spawned from the shell, for example. -Often, a `fork` call will eventually be followed by an `exec`, which will in -turn close (most of) the duplicated port rights. Unfortunately, this cannot be -known at the time the `fork` executing, so the code calling `fork` has to be -modified, and the `fork`, `exec` combo be replaced by a `posix_spawn` call, for -example, to avoid this work of duplicating each port right, then closing each -again. +Often, a `fork` call will eventually be followed by an `exec`, which [[may in +turn close|open_issues/secure_file_descriptor_handling]] (most of) the +duplicated port rights. Unfortunately, this cannot be known at the time the +`fork` executing, so in order to optimize this, the code calling `fork` has to +be modified instead, and the `fork`, `exec` combo be replaced by a +`posix_spawn` call, for example, to avoid this work of duplicating each port +right, then closing each again. As far as we know, Cygwin has the same problem of `fork` being a nontrivial operation. Perhaps we can learn from what they're been doing? Also, perhaps @@ -51,6 +52,11 @@ they have patches for software packages, to avoid using `fork` followed by ([[!taglink open_issue_glibc]]). +## Related + + * [[secure file descriptor handling]]. + + # External * [*How fork(2) ought to be*](http://www.greenend.org.uk/rjk/fork.html) by diff --git a/hurd/glibc/hurd-specific_api.mdwn b/hurd/glibc/hurd-specific_api.mdwn index aeb63d91..75220279 100644 --- a/hurd/glibc/hurd-specific_api.mdwn +++ b/hurd/glibc/hurd-specific_api.mdwn @@ -1,17 +1,18 @@ -[[!meta copyright="Copyright © 2002, 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Hurd-specific glibc API"]] These functions have meaning only under Hurd. They are needed to get port -names that are used in native Hurd API (the RPC calls to servers). The `.defs` +names that are used in native Hurd API (the [[RPC]]s to servers). The `.defs` and `.h` files can be found in `/include/hurd` when all development files are installed (Debian package `hurd-dev`.) Note that `.defs` are not included in C programs -- they are used to produce `.h` files. @@ -157,7 +158,7 @@ programs -- they are used to produce `.h` files.

thread_t
hurd_thread_self (void);
-
Return the current thread's thread port. This is a cheap operation (no system call), but it relies on Hurd signal state being set up.
+
Return the current thread's thread port. This is a cheap operation (no [[system call]]), but it relies on Hurd signal state being set up.

error_t
diff --git a/hurd/networking.mdwn b/hurd/networking.mdwn index ff16eb25..bdf9def2 100644 --- a/hurd/networking.mdwn +++ b/hurd/networking.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2000, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] For each supported `PF_*` protocol family, there is a file `/servers/socket/N` where `N` is the numberic value fo the `PF_*` symbol. Right now @@ -17,10 +18,10 @@ where `N` is the numberic value fo the `PF_*` symbol. Right now User programs open those files, and use the `socket_create` [[RPC]] to make a new socket. With that socket, they can use the other `socket_*` RPCs and also the `io_*` RPCs. The `socket_*` RPCs are essentially clones of the [[Unix]] -syscalls in question. +[[system call]]s in question. The only exception is `sockaddrs`, which are implemented as [[ports|libports]] -instead of the opaque data arrays they are in the syscalls. You manipulate +instead of the opaque data arrays they are in the system calls. You manipulate `sockaddr` ports with the `socket_create_address`, `socket_fabricate_address`, and `socket_whatis_address` calls. The `sockaddr` port is then used in socket calls like `socket_connect` and `socket_accept`. diff --git a/hurd/ng/microkernelcoyotos.mdwn b/hurd/ng/microkernelcoyotos.mdwn index cdf4e1bf..2340901d 100644 --- a/hurd/ng/microkernelcoyotos.mdwn +++ b/hurd/ng/microkernelcoyotos.mdwn @@ -2,7 +2,9 @@ [Coyotos](http://www.coyotos.org/index.html) is a microkernel and OS and the successor of EROS, that itself is the successor of KeyKOS. A more complete history can be found [here](http://www.coyotos.org/history.html). Its main objectives are to correcte some shortcomings of EROS, demonstrate that an atomic kernel design scales well, and (eventually) to completely formally verify both the kernel and critical system components by writing them in a new language called [bitc](http://www.bitc-lang.org/). [See [l4.verified](http://nicta.com.au/research/projects/l4.verified) for work on formally verifying an L4 microkernel.] -Coyotos is an orthogonally persistent pure capability system. It uses continuation based unbuffered asynchronous IPC (actually it's synchronous IPC with asynchronous syscalls). +Coyotos is an orthogonally persistent pure capability system. It uses +continuation based unbuffered asynchronous IPC (actually it's synchronous IPC +with asynchronous [[system calls]]). TODO: explain these terms and (more important) their consequences on system design. diff --git a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn index 4eeef6ee..0d91dee7 100644 --- a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn +++ b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn @@ -6,10 +6,11 @@ This comparison is about a simple situation: there is a parent process P, which # Trivial Confinement -For trivial confinement, there is a system call to create a process from some memory pages. P performs the following steps: +For trivial confinement, there is a [[system call]] to create a process from +some memory pages. P performs the following steps: * Allocate some memory and put the code image of the child into that memory. This can be done by P, or for example by the file system which then gives the resulting memory (space bank) to P. -* Perform the system call on that memory. The result is a capability to C. +* Perform the [[system call]] on that memory. The result is a capability to C. * Send A to C using the returned capability. Note that it is up to the implementation of the system what happens with P's access to the memory which holds the child. For example, it is probably a good idea if it is at least unmapped, so it cannot accidentily write things in it. It could even be revoked, so that it can't write things in it, even if it wants to. @@ -32,7 +33,16 @@ This mechanism is targeted at a specific use pattern, namely that a process is c # POSIX Fork -POSIX fork, or rather fork+exec, is how things are done on many current systems. It may be insightful to see it included in the comparison, especially for people who are new to the subject. There are two system calls, fork and exec. Fork will create a clone of the current process, including all the capabilities (that is, file descriptors) of the parent (except the ones which have explicitly been excluded). Exec is a system call which really goes to the filesystem, not the kernel (although on systems which use it, the filesystem usually resides in the kernel), and asks it to spawn a new process from the contents of a certain path in place of the caller. This passes all capabilities to the new process. The procedure is: +POSIX fork, or rather fork+exec, is how things are done on many current +systems. It may be insightful to see it included in the comparison, especially +for people who are new to the subject. There are two [[system call]]s, fork and +exec. Fork will create a clone of the current process, including all the +capabilities (that is, file descriptors) of the parent (except the ones which +have explicitly been excluded). Exec is a [[system call]] which really goes to +the filesystem, not the kernel (although on systems which use it, the +filesystem usually resides in the kernel), and asks it to spawn a new process +from the contents of a certain path in place of the caller. This passes all +capabilities to the new process. The procedure is: * P calls fork(), creating P'. * P' drops B. @@ -67,7 +77,7 @@ Except for the control, there is really only one other difference, and that's ad What it doesn't do is protect the code image against bugs in P. In the constructor the trusted and well-tested constructor code is handling the image, for trivial confinement the (very possibly) buggy program P. In particular, when starting a program from a file system, with trivial confinement the operation is: * Ask the file system for the code, receive a capability to a space bank with a copy (on write) of it. -* Make the system call to turn it into a program. +* Make the [[system call]] to turn it into a program. Now this isn't much more complicated than the constructor which does: diff --git a/hurd/translator/wishlist_2.mdwn b/hurd/translator/wishlist_2.mdwn index a927db55..77f39644 100644 --- a/hurd/translator/wishlist_2.mdwn +++ b/hurd/translator/wishlist_2.mdwn @@ -70,7 +70,17 @@ Here's an [idea](http://www.circlemud.org/~jelson/software/fusd/docs/node13.html * "One particularly interesting application of FUSD that we've found very useful is as a way to let regular user-space libraries export device file APIs. For example, imagine you had a library which factored large composite numbers. Typically, it might have a C interface--say, a function called `int *factorize(int bignum)`. With FUSD, it's possible to create a device file interface--say, a device called `/dev/factorize` to which clients can `write(2)` a big number, then `read(2)` back its factors. -* This may sound strange, but device file APIs have at least three advantages over a typical library API. First, it becomes much more language independent--any language that can make system calls can access the factorization library. Second, the factorization code is running in a different address space; if it crashes, it won't crash or corrupt the caller. Third, and most interestingly, it is possible to use `select(2)` to wait for the factorization to complete. `select(2)` would make it easy for a client to factor a large number while remaining responsive to other events that might happen in the meantime. In other words, FUSD allows normal user-space libraries to integrate seamlessly with UNIX's existing, POSIX-standard event notification interface: `select(2)`." +* This may sound strange, but device file APIs have at least three advantages + over a typical library API. First, it becomes much more language + independent--any language that can make [[system call]]s can access the + factorization library. Second, the factorization code is running in a + different address space; if it crashes, it won't crash or corrupt the + caller. Third, and most interestingly, it is possible to use `select(2)` to + wait for the factorization to complete. `select(2)` would make it easy for a + client to factor a large number while remaining responsive to other events + that might happen in the meantime. In other words, FUSD allows normal + user-space libraries to integrate seamlessly with UNIX's existing, + POSIX-standard event notification interface: `select(2)`." ## Mail diff --git a/qemu.mdwn b/qemu.mdwn index 19b5fb9f..d7cea5ad 100644 --- a/qemu.mdwn +++ b/qemu.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2005, 2007, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2005, 2007, 2008, 2009, 2010 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] QEMU is free software written by Fabrice Bellard that implements a fast processor [[emulator|emulation]], allowing a user to run one operating system @@ -19,8 +19,8 @@ reasonable speed while being easy to port on new host CPUs. QEMU has two operating modes: * User mode emulation: QEMU can launch Linux processes compiled for one CPU - on another CPU. Linux system calls are converted because of endianness and - 32/64 bit mismatches. Wine and Dosemu are the main targets for QEMU. + on another CPU. Linux [[system call]]s are converted because of endianness + and 32/64 bit mismatches. Wine and Dosemu are the main targets for QEMU. * System mode emulation: QEMU emulates a full system, including a processor and various peripherials. It enables easier testing and debugging of diff --git a/system_call.mdwn b/system_call.mdwn new file mode 100644 index 00000000..197889cb --- /dev/null +++ b/system_call.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +In an [[UNIX]]-like system, a *system call* (*syscall*) is used to request all +kinds of functionality from the operating system kernel. + +A [[microkernel]]-based system typically won't offer a lot of system calls -- +apart from one central one, and that is *send message* -- but instead [[RPC]]s +will be used instead. + +In the [[GNU Hurd|hurd]], a lot of what is traditionlly considered to be a UNIX +system call is implemented (primarily by means of [[RPC]]) inside [[glibc]]. -- cgit v1.2.3 From cd782d77c1e90976cb6dacf6ba78ba762f145a50 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 30 Nov 2010 10:39:28 +0100 Subject: Been reading another LWN issue... --- capability.mdwn | 14 ++-- community/gsoc/project_ideas.mdwn | 2 +- community/gsoc/project_ideas/valgrind.mdwn | 80 ---------------------- glibc.mdwn | 9 ++- glibc/fallocate.mdwn | 17 +++++ glibc/fork.mdwn | 18 +++-- glibc/signals.mdwn | 32 +++++++++ hurd/glibc/hurd-specific_api.mdwn | 8 ++- hurd/ng/trivialconfinementvsconstructorvsfork.mdwn | 24 ++++--- hurd/translator/magic.mdwn | 11 +-- open_issues/code_analysis.mdwn | 12 +++- open_issues/debugging.mdwn | 16 +++-- open_issues/multithreading.mdwn | 4 +- open_issues/nightly_builds_deb_packages.mdwn | 6 ++ open_issues/secure_file_descriptor_handling.mdwn | 9 +++ open_issues/unit_testing.mdwn | 9 ++- open_issues/valgrind.mdwn | 80 ++++++++++++++++++++++ persistency.mdwn | 11 +-- unix.mdwn | 48 +++++++++++-- unix/file_descriptor.mdwn | 13 ++++ virtualization.mdwn | 7 +- 21 files changed, 296 insertions(+), 134 deletions(-) delete mode 100644 community/gsoc/project_ideas/valgrind.mdwn create mode 100644 glibc/fallocate.mdwn create mode 100644 glibc/signals.mdwn create mode 100644 open_issues/valgrind.mdwn create mode 100644 unix/file_descriptor.mdwn (limited to 'hurd') diff --git a/capability.mdwn b/capability.mdwn index 367ea163..d78810d5 100644 --- a/capability.mdwn +++ b/capability.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A capability is a protected reference. It is a reference in that it designates an object; it is protected in that in cannot be @@ -27,7 +28,6 @@ sent a string to identify the file to B, the identifier lacks a than A intended. Be ensuring that [[designation]] and [[authorization]] are always bound together, these problems are avoided. -[[Unix]] file descriptors can be viewed as capabilities. Unix file -descriptors do not survive reboot, that is, they are not -[[persistent|persistency]]. To work around this, [[ACL]]s are used to -recover authority. +[[UNIX file descriptors|unix/file_descriptor]] can be viewed as capabilities. +They do not survive reboot, that is, they are not [[persistent|persistency]]. +To work around this, [[ACL]]s are used to recover authority. diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index b039608f..649e05c1 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -106,4 +106,4 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]] +[[!inline pages="open_issues/valgrind" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn deleted file mode 100644 index 7d68e82d..00000000 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -[[!meta title="Porting Valgrind to the Hurd"]] - -[Valgrind](http://valgrind.org/) is an extremely useful debugging tool for memory errors. -(And some other kinds of hard-to-find errors too.) -Aside from being useful for program development in general, -a Hurd port will help finding out why certain programs segfault on the Hurd, -although they work on Linux. -Even more importantly, it will help finding bugs in the Hurd servers themselfs. - -To keep track of memory use, -Valgrind however needs to know how each [[system call]] affects the validity of memory regions. -This knowledge is highly kernel-specific, -and thus Valgrind needs to be explicitely ported for every system. - -Such a port involves two major steps: -making Valgrind understand how kernel traps work in general on the system in question; -and how all the individual kernel calls affect memory. -The latter step is where most of the work is, -as the behaviour of each single [[system call]] needs to be described. - -Compared to Linux, -Mach (the microkernel used by the Hurd) has very few kernel traps. -Almost all [[system call]]s are implemented as RPCs instead -- -either handled by Mach itself, or by the various Hurd servers. -All RPCs use a pair of mach\_msg() invocations: -one to send a request message, and one to receive a reply. -However, while all RPCs use the same mach\_msg() trap, -the actual effect of the call varies greatly depending on which RPC is invoked -- -similar to the ioctl() call on Linux. -Each request thus must be handled individually. - -Unlike ioctl(), -the RPC invocations have explicit type information for the parameters though, -which can be retrieved from the message header. -By analyzing the parameters of the RPC reply message, -Valgrind can know exactly which memory regions are affected by that call, -even without specific knowledge of the RPC in question. -Thus implementing a general parser for the reply messages -will already give Valgrind a fairly good approximation of memory validity -- -without having to specify the exact semantic of each RPC by hand. - -While this should make Valgrind quite usable on the Hurd already, it's not perfect: -some RPCs might return a buffer that is only partially filled with valid data; -or some reply parameters might be optional, -and only contain valid data under certain conditions. -Such specific semantics can't be deduced from the message headers alone. -Thus for a complete port, -it will still be necessary to go through the list of all known RPCs, -and implement special handling in Valgrind for those RPCs that need it. - -The goal of this task is at minimum to make Valgrind grok Mach traps, -and to implement the generic RPC handler. -Ideally, specific handling for RPCs needing it should also be implemented. - -Completing this project will require digging into Valgrind's handling of [[system call]]s, -and into Hurd RPCs. -It is not an easy task, but a fairly predictable one -- -there shouldn't be any unexpected difficulties, -and no major design work is necessary. -It doesn't require any specific previous knowledge: -only good programming skills in general. -On the other hand, -the student will obtain a good understanding of Hurd RPCs while working on this task, -and thus perfect qualifications for Hurd development in general :-) - -Possible mentors: Samuel Thibault (youpi) - -Exercise: As a starter, -students can try to teach valgrind a couple of Linux ioctls, -as this will make them learn how to use the read/write primitives of valgrind. diff --git a/glibc.mdwn b/glibc.mdwn index 2eba3667..124216d9 100644 --- a/glibc.mdwn +++ b/glibc.mdwn @@ -36,11 +36,18 @@ Porting glibc to a specific architecture is non-trivial. * [[open_issues/secure_file_descriptor_handling]] +## Concepts + + * [[environment_variables]] + + * [[signals]] + + ## Individual functions Some of these are well-known as [[UNIX]] [[system call]]s. - * [[environment_variables]] + * [[fallocate]] * [[fork]] diff --git a/glibc/fallocate.mdwn b/glibc/fallocate.mdwn new file mode 100644 index 00000000..3aecf16b --- /dev/null +++ b/glibc/fallocate.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Not yet implemented for the GNU Hurd in [[glibc]]. + + +# External + + * [*Punching holes in files*](http://lwn.net/Articles/415889/), Jonathan + Corbet, 2010-11-17. diff --git a/glibc/fork.mdwn b/glibc/fork.mdwn index e8556a91..378fe835 100644 --- a/glibc/fork.mdwn +++ b/glibc/fork.mdwn @@ -14,10 +14,10 @@ Our implementation in [[glibc]] is and needs to be rather bulky. For example, it has to duplicate all port rights for the new [[Mach task|microkernel/mach/task]]. The address space can simply be duplicated by -standard means of the [[microkernel/Mach]], but as [[file descriptor]]s (for -example) are a concept that is implemented inside [[glibc]] (based on [[Mach -port|microkernel/mach/port]]s), these have to be duplicated from userspace, -which requires a small number of [[RPC]] for each of them. +standard means of the [[microkernel/Mach]], but as [[unix/file_descriptor]]s +(for example) are a concept that is implemented inside [[glibc]] (based on +[[Mach port|microkernel/mach/port]]s), these have to be duplicated from +userspace, which requires a small number of [[RPC]] for each of them. In sum, [[this affects performance|open_issues/performance/fork]] when new processes are continuously being spawned from the shell, for example. @@ -43,7 +43,7 @@ they have patches for software packages, to avoid using `fork` followed by ([[!taglink open_issue_glibc]]). * Include de-duplicate information from elsewhere: [[hurd-paper]], - [[hurd-talk]] [[hurd/ng/trivialconfinementvsconstructorvsfork]], + [[hurd-talk]], [[hurd/ng/trivialconfinementvsconstructorvsfork]], [[open_issues/resource_management_problems/zalloc_panics]] ([[!taglink open_issue_glibc open_issue_documentation]]). @@ -54,13 +54,11 @@ they have patches for software packages, to avoid using `fork` followed by ## Related - * [[secure file descriptor handling]]. + * [[open_issues/secure_file_descriptor_handling]]. # External - * [*How fork(2) ought to be*](http://www.greenend.org.uk/rjk/fork.html) by - Richard Kettlewell. + * {{$unix#djb_self-pipe}}. - * [*The self-pipe trick*](http://cr.yp.to/docs/selfpipe.html) by - D. J. Bernstein. + * {{$unix#rjk_fork}}. diff --git a/glibc/signals.mdwn b/glibc/signals.mdwn new file mode 100644 index 00000000..40fdc0e1 --- /dev/null +++ b/glibc/signals.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*[[UNIX]] signals* are a means to asynchronously invoke a specific function +(*signal handler*). This may impact on [[system call]]s that are executing at +the same time in that they may be completely aborted, return incomplete +results, scheduled for restarting, or cause signal delivery to be blocked upon +the system call's completion. + +An explanation can be found in the relevant standards, an overview, including +UNIX signals' deficiencies is given in {{$unix#2010_brown_ghosts_3}}, for +example. + +The UNIX signalling mechanism is implemented for the GNU Hurd by means of a +separate signal-handling thread that is part of every process. This makes +handling of signals a separate thread of control. + + * [[SA_SIGINFO, SA_SIGACTION|open_issues/sa_siginfo_sa_sigaction]] + + +# External + + * {{$unix#djb_self-pipe}}. + + * {{$unix#rjk_fork}}. diff --git a/hurd/glibc/hurd-specific_api.mdwn b/hurd/glibc/hurd-specific_api.mdwn index 75220279..7ead63cd 100644 --- a/hurd/glibc/hurd-specific_api.mdwn +++ b/hurd/glibc/hurd-specific_api.mdwn @@ -82,7 +82,13 @@ programs -- they are used to produce `.h` files.
openport (io_t port, int flags);

-
Open a file descriptor on a port. FLAGS are as for open; flags affected by io_set_openmodes are not changed by this. If successful, this consumes a user reference for PORT (which will be deallocated on close.) See <hurd/io.defs> and <hurd/io.h>.
+
Open a [[unix/file_descriptor]] on a [[microkernel/mach/port]]. FLAGS + are as for open; flags affected by io_set_openmodes are + not changed by this. If successful, this consumes a user reference for + PORT (which will be deallocated on close.) See + <hurd/io.defs> and + <hurd/io.h>. +

task_t
diff --git a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn index 0d91dee7..949895e7 100644 --- a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn +++ b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn @@ -34,15 +34,15 @@ This mechanism is targeted at a specific use pattern, namely that a process is c # POSIX Fork POSIX fork, or rather fork+exec, is how things are done on many current -systems. It may be insightful to see it included in the comparison, especially -for people who are new to the subject. There are two [[system call]]s, fork and -exec. Fork will create a clone of the current process, including all the -capabilities (that is, file descriptors) of the parent (except the ones which -have explicitly been excluded). Exec is a [[system call]] which really goes to -the filesystem, not the kernel (although on systems which use it, the -filesystem usually resides in the kernel), and asks it to spawn a new process -from the contents of a certain path in place of the caller. This passes all -capabilities to the new process. The procedure is: +systems. It may be insightful to see it included in the comparison, especially +for people who are new to the subject. There are two [[system call]]s, fork +and exec. Fork will create a clone of the current process, including all the +capabilities (that is, [[unix/file_descriptor]]s) of the parent (except the +ones which have explicitly been excluded). Exec is a [[system call]] which +really goes to the filesystem, not the kernel (although on systems which use +it, the filesystem usually resides in the kernel), and asks it to spawn a new +process from the contents of a certain path in place of the caller. This +passes all capabilities to the new process. The procedure is: * P calls fork(), creating P'. * P' drops B. @@ -62,7 +62,11 @@ In contrast, the other two options don't pass anything by default. If there is a The problem of fork+exec can be solved. It is if the default would be to not pass capabilities to the new process, but specify a list of capabilities that it should keep, or (like in the other cases) pass them over a new channel which is implicitly created during the fork. However, in that case the only difference with trivial confinement is that P' dies in the process (and thus must be created to prevent P from dying). Almost any use of exec is in practice preceded by a fork for this purpose. It would be easier to make trivial confinement the default operation and let P die directly after it in the rare case that it should. -The only reason for continuing to use fork+exec would be that it is what existing programs do. However, they break anyway if they need to specify which file descriptors to pass. So they need to be adapted. Therefore, it's better to make the usual spawning method the primitive one, and emulate the other. +The only reason for continuing to use fork+exec would be that it is what +existing programs do. However, they break anyway if they need to specify which +[[unix/file_descriptor]]s to pass. So they need to be adapted. Therefore, it's +better to make the usual spawning method the primitive one, and emulate the +other. # Trivial Confinement vs Constructor diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn index 06ee798b..84bacdfb 100644 --- a/hurd/translator/magic.mdwn +++ b/hurd/translator/magic.mdwn @@ -1,20 +1,21 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] The magic translator provides `/dev/fd`. $ showtrans /dev/fd /hurd/magic --directory fd -The `/dev/fd` directory holds the open file descriptors for your current -process. You can't see them with `ls -l /dev/fd/` but you can see them +The `/dev/fd` directory holds the open [[unix/file_descriptor]]s for your +current process. You can't see them with `ls -l /dev/fd/` but you can see them individually like this: $ ls -l /dev/fd/0 diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn index 98447e98..ad104e68 100644 --- a/open_issues/code_analysis.mdwn +++ b/open_issues/code_analysis.mdwn @@ -8,7 +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]]."]]"""]] -There is static and dynamic code analysis. +There is static and dynamic code analysis. This overlaps with [[debugging]]. * [[GCC]]'s warnings. Yes, really. @@ -29,3 +29,13 @@ There is static and dynamic code analysis. * * + + * [[Valgrind]] + + * + + * + + * + + * diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn index 95b7bf9b..e66a086f 100644 --- a/open_issues/debugging.mdwn +++ b/open_issues/debugging.mdwn @@ -18,7 +18,7 @@ We have debugging infrastructure. For example: * [[GNU Mach debugging|microkernel/mach/gnumach/debugging]] * [[GNU Hurd debugging|hurd/debugging]], including - [[hurd/debugging/rpctrace]] and more. + [[hurd/debugging/rpctrace]], and more. # To Do @@ -29,14 +29,20 @@ We have debugging infrastructure. For example: * [[profiling]] - * *[Checkpoint/restart](http://lwn.net/Articles/412749/) allows the state of - a set of processes to be saved to persistent storage, then restarted at - some future time* -- quoting from Jonathan Corbet's 2010 Linux Kernel - Summit report. + * *Checkpoint/restart allows the state of a set of processes to be saved to + persistent storage, then restarted at some future time* -- quoting from + Jonathan Corbet's [2010 Linux Kernel Summit + report](http://lwn.net/Articles/412749/). This is surely a very useful facility to have for reproducing failures, for example. But on the other hand it's questionable how it can help with debugging failures in [[GNU Hurd server|hurd/translator]]s' interactions, as their state is typically spread between several processes. + Continues: , which introduces + . + * [[locking]] + + * , or -- + just two examples; there's a lot of such stuff for Linux. diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index 81b96280..170734fd 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -22,9 +22,11 @@ Alternative approaches: * Continuation-passing style + * [[Erlang-style_parallelism]] + * [libtcr - Threaded Coroutine Library](http://oss.linbit.com/libtcr/) - * [[Erlang-style_parallelism]] + * --- diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index 29219c2a..9f5e2373 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -18,4 +18,10 @@ packages. --- +There is infrastructure available to test whole OS installations. + + * + +--- + See also [[nightly_builds]]. diff --git a/open_issues/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn index c9956ede..1a514e69 100644 --- a/open_issues/secure_file_descriptor_handling.mdwn +++ b/open_issues/secure_file_descriptor_handling.mdwn @@ -8,7 +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]]."]]"""]] +[[!tag open_issue_glibc]] + `O_CLOEXEC`, `dup3` et al.; see . [[tschwinge]] once worked on this, posted patches to libc-alpha. This works needs to be resumed and finished. + +--- + +In an interesting point is made: *you [may] +want some [[unix/file_descriptor]] to still be open if 'exec' fails, but you +don't want it to be open after the exec succeeds*. [[I|tschwinge]]'m not sure +whether our current `O_CLOEXEC` implementation adheres to that. diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn index 80a2860a..d50f5f6d 100644 --- a/open_issues/unit_testing.mdwn +++ b/open_issues/unit_testing.mdwn @@ -46,7 +46,14 @@ abandoned). * [*[ANNOUNCE] ktest.pl: Easy and flexible testing script for Linux Kernel Developers*](http://lwn.net/Articles/412302/) by Steven Rostedt, - 2010-10-28. + 2010-10-28. [v2](http://lwn.net/Articles/414064/), 2010-11-08. + + +# Related + + * [[nightly_builds]] + + * [[nightly_builds_deb_packages]] * -- ``comprehensive testing and benchmarking platform''. This one might be useful for [[performance]] diff --git a/open_issues/valgrind.mdwn b/open_issues/valgrind.mdwn new file mode 100644 index 00000000..2b0624d7 --- /dev/null +++ b/open_issues/valgrind.mdwn @@ -0,0 +1,80 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Porting Valgrind to the Hurd"]] + +[Valgrind](http://valgrind.org/) is an extremely useful debugging tool for memory errors. +(And some other kinds of hard-to-find errors too.) +Aside from being useful for program development in general, +a Hurd port will help finding out why certain programs segfault on the Hurd, +although they work on Linux. +Even more importantly, it will help finding bugs in the Hurd servers themselfs. + +To keep track of memory use, +Valgrind however needs to know how each [[system call]] affects the validity of memory regions. +This knowledge is highly kernel-specific, +and thus Valgrind needs to be explicitely ported for every system. + +Such a port involves two major steps: +making Valgrind understand how kernel traps work in general on the system in question; +and how all the individual kernel calls affect memory. +The latter step is where most of the work is, +as the behaviour of each single [[system call]] needs to be described. + +Compared to Linux, +[[microkernel/Mach]] (the microkernel used by the Hurd) has very few kernel traps. +Almost all [[system call]]s are implemented as [[RPC]]s instead -- +either handled by Mach itself, or by the various [[Hurd servers|hurd/translator]]. +All RPCs use a pair of `mach_msg` invocations: +one to send a request message, and one to receive a reply. +However, while all RPCs use the same `mach_msg` trap, +the actual effect of the call varies greatly depending on which RPC is invoked -- +similar to the `ioctl` call on Linux. +Each request thus must be handled individually. + +Unlike `ioctl`, +the RPC invocations have explicit type information for the parameters though, +which can be retrieved from the message header. +By analyzing the parameters of the RPC reply message, +Valgrind can know exactly which memory regions are affected by that call, +even without specific knowledge of the RPC in question. +Thus implementing a general parser for the reply messages +will already give Valgrind a fairly good approximation of memory validity -- +without having to specify the exact semantic of each RPC by hand. + +While this should make Valgrind quite usable on the Hurd already, it's not perfect: +some RPCs might return a buffer that is only partially filled with valid data; +or some reply parameters might be optional, +and only contain valid data under certain conditions. +Such specific semantics can't be deduced from the message headers alone. +Thus for a complete port, +it will still be necessary to go through the list of all known RPCs, +and implement special handling in Valgrind for those RPCs that need it. + +The goal of this task is at minimum to make Valgrind grok Mach traps, +and to implement the generic RPC handler. +Ideally, specific handling for RPCs needing it should also be implemented. + +Completing this project will require digging into Valgrind's handling of [[system call]]s, +and into Hurd RPCs. +It is not an easy task, but a fairly predictable one -- +there shouldn't be any unexpected difficulties, +and no major design work is necessary. +It doesn't require any specific previous knowledge: +only good programming skills in general. +On the other hand, +the student will obtain a good understanding of Hurd RPCs while working on this task, +and thus perfect qualifications for Hurd development in general :-) + +Possible mentors: Samuel Thibault (youpi) + +Exercise: As a starter, +students can try to teach valgrind a couple of Linux ioctls, +as this will make them learn how to use the read/write primitives of valgrind. diff --git a/persistency.mdwn b/persistency.mdwn index f5347a4e..36f90c8a 100644 --- a/persistency.mdwn +++ b/persistency.mdwn @@ -1,18 +1,19 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A persistent object is an object that survives reboot. On [[Unix]], files and directories are persistent but -processes and file descriptors are not. [[microkernel/EROS]] is +processes and [[unix/file_descriptor]]s are not. [[microkernel/EROS]] is an example of an orthogonally persistent system: -processes and capabilities also survive reboot. To a +processes and [[capabilities|capability]] also survive reboot. To a process, it generally only looks as if it had not been scheduled for a long time; the rest of its environment remains essentially the indistinguishable. diff --git a/unix.mdwn b/unix.mdwn index 601b36d1..bf361e2e 100644 --- a/unix.mdwn +++ b/unix.mdwn @@ -19,9 +19,49 @@ License|/fdl]]."]]"""]] UNIX*](http://www.informit.com/articles/printerfriendly.aspx?p=691503), an article by David Chisnall. - * [*Ghosts of Unix Past: a historical search for design - patterns*](http://lwn.net/Articles/411845/) (2010-10-27) by Neil Brown, - including file descriptors and the single, hierarchical namespace. + * The first in the series, {{$2010_brown_ghosts_1}} introduces the concepts + of [[file_descriptor]]s and the single, hierarchical [[namespace]]. + + Next, {{$2010_brown_ghosts_2}} discusses issues with *conflated designs* + such as the `mount` command (a problem we have partly solved / solved + differently with our [[hurd/translator]] approach and the + [[hurd/virtual_file_system]]), and the plethora of flags that can be passed + to the `open` [[system_call]]. + + In {{$2010_brown_ghosts_3}}, he deals with *unfixable designs*, such as + [[UNIX signals|glibc/signals]] and the *UNIX permission model* (which is + clearly inferior to a [[capability]]-based system). * [*UNIX File Permissions*](http://www.greenend.org.uk/rjk/2004/perms.html) - (2004) by Richard Kettlewell. + (2004) by Richard Kettlewell. ([[!taglink open_issue_documentation]]) + + +[[!ymlfront data=""" + +djb_self-pipe: + + D. J. Bernstein's [*self-pipe trick*](http://cr.yp.to/docs/selfpipe.html) + +rjk_fork: + + Richard Kettlewell's suggestions about [*how fork(2) ought to + be*](http://www.greenend.org.uk/rjk/fork.html) + +2010_brown_ghosts_1: + + "Neil Brown's 2010-10-27 article [*Ghosts of Unix Past: a historical search + for design patterns*](http://lwn.net/Articles/411845/)" + +2010_brown_ghosts_2: + + "Neil Brown's 2010-11-04 article [*Ghosts of Unix past, part 2: Conflated + designs*](http://lwn.net/Articles/412131/)" + +2010_brown_ghosts_3: + + "Neil Brown's 2010-11-16 article [*Ghosts of Unix past, part 3: Unfixable + designs*](http://lwn.net/Articles/414618/)" + +"""]] diff --git a/unix/file_descriptor.mdwn b/unix/file_descriptor.mdwn new file mode 100644 index 00000000..16e03fdf --- /dev/null +++ b/unix/file_descriptor.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A *file descriptor* is a [[concept]] of [[UNIX]], and represents a +non-[[persistent|persistency]] handle to an object (a file, for example). With +respect to specific aspects, it is comparable to a [[capability]]. diff --git a/virtualization.mdwn b/virtualization.mdwn index 3a207ae8..78457eb9 100644 --- a/virtualization.mdwn +++ b/virtualization.mdwn @@ -6,8 +6,11 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + * [[hurd/virtualization]] in the GNU Hurd's context. + # External -- cgit v1.2.3 From 238c43499c4e08562024c3ef59e50aa365b5f1b2 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 7 Dec 2010 14:26:40 +0100 Subject: Some bits about L4 and Coyotos. --- history/port_to_l4.mdwn | 10 ++- hurd/ng.mdwn | 2 - hurd/ng/choiceofmicrokernel.mdwn | 4 - hurd/ng/issues_with_mach.mdwn | 12 --- hurd/ng/microkernelcoyotos.mdwn | 11 --- hurd/what_is_the_gnu_hurd.mdwn | 23 ++++-- kernel.mdwn | 21 +++++ microkernel.mdwn | 32 ++++++-- microkernel/coyotos.mdwn | 30 +++++++ microkernel/l4.mdwn | 21 +++++ unix.mdwn | 2 + unsorted/HurdOnL4.mdwn | 173 --------------------------------------- unsorted/HurdOnL4/menu.lst | 55 ------------- unsorted/PortToL4.mdwn | 42 ---------- 14 files changed, 123 insertions(+), 315 deletions(-) delete mode 100644 hurd/ng/choiceofmicrokernel.mdwn delete mode 100644 hurd/ng/issues_with_mach.mdwn delete mode 100644 hurd/ng/microkernelcoyotos.mdwn create mode 100644 kernel.mdwn create mode 100644 microkernel/coyotos.mdwn create mode 100644 microkernel/l4.mdwn delete mode 100644 unsorted/HurdOnL4.mdwn delete mode 100644 unsorted/HurdOnL4/menu.lst delete mode 100644 unsorted/PortToL4.mdwn (limited to 'hurd') diff --git a/history/port_to_l4.mdwn b/history/port_to_l4.mdwn index cdf048e6..b58c0d91 100644 --- a/history/port_to_l4.mdwn +++ b/history/port_to_l4.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2007, 2008, 2009 -Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, +2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -100,3 +100,9 @@ A lange number of discussion threads can be found in the archives of the > that we had come to envision in terms of interfaces and description of the > system's structure. The new name was selected, if I recall correctly, as it > clearly wasn't the Hurd nor the Hurd based on L4. + + +The source code is still available in [CVS module +`hurd-l4`](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/) (note that +this repository has in the beginning also been used for Neal's +[[microkernel/Viengoos]]). diff --git a/hurd/ng.mdwn b/hurd/ng.mdwn index fb4d742f..de33949d 100644 --- a/hurd/ng.mdwn +++ b/hurd/ng.mdwn @@ -10,7 +10,6 @@ These pages try to summarize the major discussions and ideas. This section explains the motivations behind the new design: - * [[Issues_with_Mach]] * [[Issues_with_L4_Pistachio]] * [[Limitations_of_the_original_Hurd_design]] @@ -64,7 +63,6 @@ A [[critique]] of the original Hurd is available. ## Implementation -* [[ChoiceOfMicrokernel]] * [[HurdInterafaces]] * [[PosixLayer]] * [[SystemStructure]] diff --git a/hurd/ng/choiceofmicrokernel.mdwn b/hurd/ng/choiceofmicrokernel.mdwn deleted file mode 100644 index 20ee6f05..00000000 --- a/hurd/ng/choiceofmicrokernel.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -TBD - -* [[MicrokernelL4]] -* [[MicrokernelCoyotos]] diff --git a/hurd/ng/issues_with_mach.mdwn b/hurd/ng/issues_with_mach.mdwn deleted file mode 100644 index 9fac498f..00000000 --- a/hurd/ng/issues_with_mach.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 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]]."]]"""]] - - * [[open issues/Resource Management Problems]] - * [[Critique]] diff --git a/hurd/ng/microkernelcoyotos.mdwn b/hurd/ng/microkernelcoyotos.mdwn deleted file mode 100644 index 2340901d..00000000 --- a/hurd/ng/microkernelcoyotos.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -# The Coyotos microkernel - -[Coyotos](http://www.coyotos.org/index.html) is a microkernel and OS and the successor of EROS, that itself is the successor of KeyKOS. A more complete history can be found [here](http://www.coyotos.org/history.html). Its main objectives are to correcte some shortcomings of EROS, demonstrate that an atomic kernel design scales well, and (eventually) to completely formally verify both the kernel and critical system components by writing them in a new language called [bitc](http://www.bitc-lang.org/). [See [l4.verified](http://nicta.com.au/research/projects/l4.verified) for work on formally verifying an L4 microkernel.] - -Coyotos is an orthogonally persistent pure capability system. It uses -continuation based unbuffered asynchronous IPC (actually it's synchronous IPC -with asynchronous [[system calls]]). - -TODO: explain these terms and (more important) their consequences on system design. - -The coyotos microkernel specification can be found [here](http://www.coyotos.org/docs/ukernel/spec.html) diff --git a/hurd/what_is_the_gnu_hurd.mdwn b/hurd/what_is_the_gnu_hurd.mdwn index 0b8f7ef6..7a7f3d43 100644 --- a/hurd/what_is_the_gnu_hurd.mdwn +++ b/hurd/what_is_the_gnu_hurd.mdwn @@ -1,17 +1,18 @@ -[[!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, +2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +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 the GNU project's replacement for [[UNIX]], a popular operating +system [[kernel]]. The Hurd is firstly a collection of protocols formalizing how different components may interact. The protocols are designed to reduce the mutual @@ -22,11 +23,19 @@ 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 Hurd is also a set of [[servers|translator]] 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 provides a compatibility layer such that compiling higher level +programs is essentially transparent; that is, by means of the [[glibc]], it +provides the same standard interfaces known from other [[UNIX]]-like systems. +Thus, for a typical user, the Hurd is intended to silently work in the +background providing the services and infrastructure which the [[microkernel]] +itself has no business implementing, but that are required for higher level +programs and libraries to operate. + 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 diff --git a/kernel.mdwn b/kernel.mdwn new file mode 100644 index 00000000..8190660e --- /dev/null +++ b/kernel.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The kernel of an operating system is a fundamental program which provides +essential resources from the hardware of the computer to other programs. + +A kernel typically runs all the time and remains resident in main memory. + +The amount of functionality and resources which it provides vary tremendously. + + * [[microkernel]] + + * [[UNIX]] diff --git a/microkernel.mdwn b/microkernel.mdwn index e2d70c01..17344689 100644 --- a/microkernel.mdwn +++ b/microkernel.mdwn @@ -1,12 +1,15 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A *microkernel* is one kind of a [[kernel]] implementation. [[Liedtke]] explains in [On Microkernel Construction](http://l4ka.org/publications/paper.php?docid=642) that a microkernel attempts to minimize the mandatory part of the operating @@ -19,12 +22,10 @@ The idea of a microkernel as explained above was first explored by Per Brinch-Hansen in 1970 in [The Nucleus of a Multiprogramming System](http://brinch-hansen.net/papers/1970a.pdf). -Other notable microkernels include [[Hydra]], [[KeyKOS]], [[Eros]] and [[L4]]. - An [introduction](http://www.cs.cornell.edu/Info/People/ulfar/ukernel/ukernel.html) by Úlfar Erlingsson and Athanasios Kyparlis (from 1996) to microkernel concepts. -[[Research]]. [[Viengoos]]. +[[Research]]. [[Microkernels_for_beginners|for_beginners]]. @@ -32,4 +33,21 @@ A 2002 article about [[microkernel_FUD|FUD]] (Fear, Uncertainty, Doubt). [[FAQ]]. -[[Mach]]. + +# Implementations + + * [[Hydra]] + + * [[KeyKOS]] + + * [[Mach]] -- used by the GNU/Hurd + + * [[EROS]] + + * [[CapROS]] + + * [[Coyotos]] + + * [[L4]] + + * [[Viengoos]] diff --git a/microkernel/coyotos.mdwn b/microkernel/coyotos.mdwn new file mode 100644 index 00000000..5ecea688 --- /dev/null +++ b/microkernel/coyotos.mdwn @@ -0,0 +1,30 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Coyotos"]] + +[*Coyotos*](http://www.coyotos.org/) is a microkernel and OS and the successor +of [[EROS]], that itself is the successor of [[KeyKOS]]. A more complete +history can be found [here](http://www.coyotos.org/history.html). Its main +objectives are to correcte some shortcomings of [[EROS]], demonstrate that an +atomic kernel design scales well, and (eventually) to completely formally +verify both the kernel and critical system components by writing them in a new +language called [bitc](http://www.bitc-lang.org/). + +Coyotos is an orthogonally [[persistent|persistency]] pure [[capability]] +system. It uses [[continuation]]-based unbuffered asynchronous [[IPC]] +(actually it's synchronous [[IPC]] with asynchronous [[system calls]]). + +TODO: explain these terms and (more important) their consequences on system +design. + +The coyotos microkernel specification can be found +[here](http://www.coyotos.org/docs/ukernel/spec.html). diff --git a/microkernel/l4.mdwn b/microkernel/l4.mdwn new file mode 100644 index 00000000..970407be --- /dev/null +++ b/microkernel/l4.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010 Free Software +Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The [*L4* microkernel](http://l4ka.org/) is an attempt to create a very small +high performace core which provides basic memory management, task and context +switching, and little else. + +[L4Ka Pistachio Home](http://l4ka.org/projects/pistachio/). + +See [l4.verified](http://nicta.com.au/research/projects/l4.verified) for work +on formally verifying an L4 microkernel. + +There was a GNU/Hurd [[history/port_to_L4]], which is now stalled. diff --git a/unix.mdwn b/unix.mdwn index bf361e2e..3cfe7771 100644 --- a/unix.mdwn +++ b/unix.mdwn @@ -10,6 +10,8 @@ License|/fdl]]."]]"""]] [[!meta title="UNIX"]] +*UNIX* is a [[kernel]] implementation. + # External diff --git a/unsorted/HurdOnL4.mdwn b/unsorted/HurdOnL4.mdwn deleted file mode 100644 index 79e7a714..00000000 --- a/unsorted/HurdOnL4.mdwn +++ /dev/null @@ -1,173 +0,0 @@ -# GNU/Hurd on L4 wiki - -## Introduction - -This page is a place for information pertaining to the efforts towards realizing the migration and porting of the [[Hurd]] such that it uses the [L4 Microkernel](http://l4ka.org/). The GNU/Hurd Operating System, sometimes just referred to as the _GNU Operating System_ is a rich and robust collection of programs and utilities which enable you to use your computer to do usefull and or entertaining things. The intent is that most any applicable software package available on the [GNU Website](http://www.gnu.org) (and many others also) will be able to be compiled and run under the resultant operating system. - -At this point (06/20/2004) this is not yet possible. Indeed, the preliminary foundations are still being developed. Nevertheless, this is a volunteer created operating system so those with the knowledge, interest, and spare time are encouraged to study and if possible contribute to the project. - -In [CVS module hurd-l4](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/), there is a [comprehensive list of items that need to be done](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd-l4/TODO). - -## Components of the System - -### The L4 Microkernel - -The kernel of an operating system is a fundamental program which provides essential resources from the hardware of the computer to other programs. A kernel typically runs all the time and remains resident in main memory. The amount of functionality and resources which it provides vary tremendously. The [L4 Microkernel](http://l4ka.org/) is an attempt to create a very small high performace core which provides basic memory management, task and context switching, and little else. - -### The Hurd - -The [Hurd](http://www.gnu.org/software/hurd/hurd.html) is a conglomeration of servers and programs which add additional functionality to a microkernel such that it is capable of utilizing additional hardware resources of the computer. It also provides a compatibility layer such that compiling higher level programs is essentially transparent; i.e. when you write a C program and compile it, you need only include standard headers and libraries and for all intents and purposes your generic program will build and run and you need never resort to unportable coding or access to hardware specific methods. - -For a typical user, The Hurd is intended to silently work in the background providing the services and infrastructure which are lacking in the microkernel but are required for higher level programs and libraries to operate. - -### GNU Programs - -For the user, this is what is desired: to run [GNU Software](http://www.gnu.org/). These programs provide a full featured, robust, and extremely effective operating system. A L4/Hurd system should be capable of compiling and executing most any software package available from GNU with little or no modification. - -Some readers may be familiar with GNU/Linux systems. When GNU/L4 is complete it should highly resemble the functionality of such systems as L4 and Hurd effectively replace the Linux kernel. The bulk of the software should be expected to run much as it does presently under the Linux kernel (or gnumach based GNU/Hurd systems). - -## Preparations - -### Build System - -There are no precompiled binaries for Hurd on L4 that I am aware of, so you will need to be able to compile the source code packages in order to experiment with it. While L4Ka will likely build on a variety of compilers and systems, the Hurd may prove troublesome unless it is built using recent GNU compilers and tools. - -I recently used [Debian Unstable](http://www.debian.org) (Sarge) with GNU gcc version 3.3, autoconf version 2.50, and automake version 1.8 to build the system with good results, although other similarly equipped systems with a good development environment, such as [Gentoo](http://www.gentoo.org) or [Slackware](http://www.slackware.com) are reported to work fine also. - -Generally, I would recommend building the packages using any very up-to-date GNU development system. I'm not going to say that you can't compile them using more exotic platforms, but I wouldn't be overly hopefull about it. I have no idea if Pistachio can be compiled under current gnuMach/Hurd systems it might be interesting to try it. - -### Making a Home for L4/Hurd - -Obviously you want to have a home for this little embryonic operating system. Currently, mine is using about 5M for the binaries and headers. If you want the source to reside with the binaries, then allow perhaps another 50M or so, but this is purely optional. - -At the moment, Hurd on L4 can't even see your hard drive, so all you need is a directory on some partition which is visible to the GRUB bootloader. A `/l4hurd` directory on your existing GNU/Linux system is probably fine for now. - -Howevever, if you have some spare disk space or an unused partition, you could optionally create a small partition for the system. This is totally unnecessary at the moment because L4/Hurd lacks hard disk drivers right now, but it is an option. Assuming that you have made some partition **X** with linux _fdisk_, set it to type 83 - Linux and use the following command to initialize it with the classic Hurd extensions: - - - -As noted, this is purely optional, in fact right now you can use any filesystem that GRUB can understand. You can even use TFTP to netboot the system. My current setup takes about 5M for the full install so obviously you don't need much space for this. - -### Boot Loader - -Just like regular GNU/Hurd, you need to use [GNU GRUB](http://www.gnu.org/software/grub/), the _GRand Unified Bootloader_ in order to boot the system. Hopefully you already have it installed, in which case adding the commands for L4/Hurd to your `menu.lst` is quite trivial. - -If you don't have GRUB installed, then you should probably take some time to get it set up. A good place to look for help is on the regular [Debian GNU/Hurd Installation Page](http://www.debian.org/ports/hurd/hurd-install) at the **3\. The Boot Loader** section. - -This is probably a bit superfluous, but you can even display a snazzy little graphic of some type on your GRUB boot menu. Here's a snip from the header of my `menu.lst` which demonstrates how to do this. - - # menu for grub - splashimage (hd0,0)/boot/grub/debian.xpm - foreground bfbfe7 - background 3f3f7f - -In the above example, my `debian.xpm` is just a 640x480 graphic in xpm format (which you can easily create with GIMP). It does add a bit of pizazz to your boot screen :-) - -In fact, I will attach a sample copy of my `menu.lst` here. It has lots of examples for booting a variety of operating systems in it. Remember that my hard drive partitions are unique to my system. - -* [[ATTACHURLmenulst]]: Sample GRUB boot menu - -## Building Hurd on L4 - -### L4Ka Pistachio - -#### Getting the Sources - -I used the latest version of L4Ka, Pistachio version 0.4. It can be obtained from the following website: - -[L4Ka Pistachio Home](http://l4ka.org/projects/pistachio/) - -#### Compiling - -Pistachio is designed to be compiled in a build directory which is independant from the source directory, so you need to create your build directory after unpacking the tarball. Furthermore, you need to pass a couple of special parameters to the configure program to set it up for use with Hurd. Here is what I did on my ia32 system: - -Note: I have my installation set up in `/l4hurd` and I am starting from within the Pistachio source top-level directory. - - $ mkdir build - $ cd build - Building and installing user-level libraries and servers/applications - $ ../user/configure --with-s0-linkbase=0x40000 --prefix=/l4hurd - $ make - $ make install - Building and installing the kernel - $ make -C ../kernel BUILDDIR=`pwd`/kernel - $ cd kernel - $ make menuconfig - $ make - $ mkdir /l4hurd/boot - $ cp ia32-kernel /l4hurd/boot - -Hopefully everything worked and there were no problems. As usual, if the build fails then scrutinize the output from `configure` and install any missing libraries or development packages. - -### CVS l4hurd - -#### Getting the sources - - You need to pull the L4 Hurd sources from the CVS tree on Savannah. The CVS access page is [The GNU/Hurd - CVS (module hurd-l4)](http://savannah.gnu.org/cvs/?group=hurd). In a nutshell, the following commands should retrieve the sources for you: - - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd-l4 - -#### Compiling - -Take a look at the README, compiling should be quite simple on any state of the art GNU development system. As per the README, and for my example, you would: - - $ autoreconf -f -i -s - $ ./configure --enable-maintainer-mode --prefix=/l4hurd - $ make - $ make install - $ strip physmem/physmem - - $ mkdir /l4hurd/boot - $ cp laden/laden /l4hurd/boot - $ cp wortel/wortel /l4hurd/boot - $ cp physmem/physmem /l4hurd/boot - -Currently (2004/08/09), physmem needs to be stripped to to avoid a memory conflict with wortel; this requirement may be fixed in the future. - -In my case it was slightly more complicated as Debian uses a wrapper system to enable the use of multiple versions of the GNU Autotools. In this case, the trick is to utilize some environment variables on the command line as follows: - - $ ACLOCAL=aclocal-1.8 AUTOMAKE=automake-1.8 autoreconf -f -i -s - -As above, hopefully this will compile cleanly; otherwise, scroll up, read any error messages, and correct them by installing required packages of the proper version. Any bad compilation problems are most likely due to you either missing or using a wrong version of something. - -## Installing - -The binaries are now installed into `/l4hurd`. All that remains is to add an entry into GRUB's `menu.lst` in order to test it out. Here's an example from my system where I have `/l4hurd` on `/dev/hda9` in my Linux system: - - title GNU Hurd on L4Ka Pistachio 0.4 - root (hd0,8) - kernel /boot/laden -D - module /boot/ia32-kernel - module /libexec/l4/sigma0 - module /boot/wortel -D - module /boot/physmem -D - module /boot/physmem - module /boot/physmem - module /boot/physmem - module /boot/physmem - -It might strike you a little odd that there are five physmem modules. This is done because wortel currently (2004/08/09) expects exactly five modules and the other modules (like the task server, auth server, etc.) have not been implemented yet. Therefore the physmem module is used as a dummy module. - -## Booting - -For me at least, I got some nifty messages and then it dropped into a simple debugging mode. As far as I know, thats all there is right now. - -Read, build, learn, code... - ---todo: add more here. - -## Experimenting - -Well, thats why you did all of this, certainly not to do anything else. Use that debugger and get experimenting. - ---todo: things to do wth the debugger - -## Conclusion - -If you followed these steps, you most likely have built and booted the latest version of Hurd on L4. I would encourage you to subscribe to the mailing list at the following URL and help in the efforts to get this nifty system up to speed: - -[l4-hurd mailing list](http://lists.gnu.org/mailman/listinfo/l4-hurd) - -And finally, this is a wiki, meaning that **you** have the ability to edit and modify this page. If you want to fix something, add more information, new sub-pages, whatever, feel free to do so. This is a great way to get a doc base up fast and keep it current, so use it like its supposed to be and have fun with Hurd on L4! - --- [[Main/BDouglasHilton]] - 20 Jun 2004 diff --git a/unsorted/HurdOnL4/menu.lst b/unsorted/HurdOnL4/menu.lst deleted file mode 100644 index 3129ea74..00000000 --- a/unsorted/HurdOnL4/menu.lst +++ /dev/null @@ -1,55 +0,0 @@ -# menu for grub -splashimage (hd0,0)/boot/grub/debian.xpm -foreground bfbfe7 -background 3f3f7f - -timeout 30 -default 0 - -title Debian Sid with Linux kernel 2.6.5 -root (hd0,1) -kernel /vmlinuz root=/dev/hda2 vga=0x318 - -title Debian Sid with old kernel -root (hd0,1) -kernel /vmlinuz.old root=/dev/hda2 vga=9 - -title Microsoft Windows 2000 -rootnoverify (hd0,3) -chainloader (hd0,3)+1 - -title FreeDOS BETA 8.0 -root (hd0,0) -chainloader +1 - -title GNU Hurd on L4Ka Pistachio 0.4 -root (hd0,8) -kernel /boot/laden -D -module /boot/ia32-kernel -module /libexec/l4/sigma0 -module /boot/wortel -D -module /boot/physmem - -title Debian GNU/Hurd (gnumach) -root (hd0,7) -kernel /boot/kernel.gz root=device:hd0s8 -module /hurd/ext2fs.static --readonly \ - --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 /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -# title Debian GNU/Hurd (oskit-mach) -# root (hd3,0) -# kernel /boot/kernel-ide -- root=hd0s1 -# module /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 device ${root-device} $(task-create) $(task-resume) -# module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -# title Debian GNU/Hurd (oskit-mach w/ remote debugging) -# root (hd3,0) -# kernel /boot/kernel-ide -d GDB_COM=1 BAUD=9600 -- root=hd0s1 -# module /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 device ${root-device} $(task-create) $(task-resume) -# module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - diff --git a/unsorted/PortToL4.mdwn b/unsorted/PortToL4.mdwn deleted file mode 100644 index fb7f0004..00000000 --- a/unsorted/PortToL4.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -**_The Hurd-L4 port has an [official page](http://www.gnu.org/software/hurd/hurd-l4.html) with more up-to-date information_** -- [[Main/OgnyanKulev]] - 05 Feb 2005 - -A group of one being led by Neal H. Walfield is working on porting the Hurd to the pistachio version of the L4 microkernel. This second generation microkernel provides a significantly different API than the one offered by the Mach microkernel, a first generation microkernel. One of the primary goals of the project, outside of porting the Hurd to L4, is to reevaluate the current Hurd abstractions and consider how they can be modified to be more general. - -I have no web page describing my efforts. There is a mailing list[1]. - -[1] - --- Neal Walfield, 18 Sep 2002 - -Neal noted [1] that there are licensing issues being worked out so no code is yet released. His work was performed in the summer of 2002 at Karlsruhe. - -[1] - --- [[Main/GrantBow]] - 21 Sep 2002 - -There are several important pages that are of interest for the L4 & hurd communities. - -* Main L4 home page - -* Hurd on L4 - -* Hurd on L4 - -* - --- [[Main/GrantBow]] - 22 May 2002 - - - --- [[Main/GrantBow]] - 24 Oct 2002 - -There was [discussion in October 2002](http://mail.gnu.org/pipermail/l4-hurd/2002-October/000727.html) about the differences between Hurd on Mach and Hurd on L4 with some interesting URLs. In the thread Okuji [responds](http://mail.gnu.org/pipermail/l4-hurd/2002-October/000728.html) confirming his document is two years old and outdated by the directions that Neal is taking in furthering this effort. The URLs in that email might be helpful to those learning more about Hurd and L4 ideas that were considered yet abandoned. - --- [[Main/GrantBow]] - 04 Jan 2003 - -A "Porting GNU Hurd to L4" website: - -* - --- [[Main/SebastianGabriel]] - 29 Sep 2003 - -The only valid L4-Hurd link on is - --- [[Main/JoachimNilsson]] - 29 Sep 2003 -- cgit v1.2.3 From a443aefc2e130efeb1c76edd91cb950d90ad6adf Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 11 Dec 2010 10:09:39 +0100 Subject: hurd/subhurd: Add use case: debugging the main Hurd system --- hurd/subhurd.mdwn | 31 +++++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) (limited to 'hurd') diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index 5b132604..84372dd1 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A sub-Hurd is like a [[neighbor_Hurd|neighborhurd]], however, makes use of some resources provided by another Hurd. For instance, backing store and the @@ -17,7 +18,8 @@ attach to them with gdb from the parent ([[debugging_via_subhurds|debugging/subhurd]]). This avoids deadlock, e.g., when the instance of gdb stops the server but requires its use. (Note: it is possible to use [[debugging/gdb/noninvasive_debugging]], but this is less -flexible.) +flexible.) Vice versa, it is also possible to use a subhurd to debug the +*main* Hurd system, for example, the latter's root file system. # Howto @@ -105,9 +107,9 @@ inside the subhurd, or to `ssh` directly into the subhurd. If you want to access the subhurd processes from the outside, e.g. for [[debugging_purposes|debugging/subhurd]] (or to get rid of a subhurd that -didn't exit cleanly...), you need to find out how main Hurd PIDs correspond to +didn't exit cleanly...), you need to find out how main Hurd [[PID]]s correspond to subhurd processes: the subhurd processes appear in the main Hurd (e.g. if doing -`ps -e`) as unknown processes, and vice versa, but the PIDs are different! To +`ps -e`) as unknown processes, and vice versa, but the [[PID]]s are different! To find out which process is which, you can simply compare the order -- while the numbers are different, the order should usually match. Often it also helps to look at the number of threads (e.g. using `ps -l`), as many servers have very @@ -119,3 +121,20 @@ characteristic thread counts. Read about using a subhurd for [[debugging_purposes|debugging/subhurd]]. Roland's tutorial about [[running_a_subhurd]]. + + +# Use Cases + +## Debugging the *Main* Hurd System + +A subhurd can be used for debugging the *main* Hurd system. This works as long +as the subhurd doesn't use any services provided by the main Hurd. For +example, if you already have a subhurd running at the time it happens, you can +use that one to debug a deadlocked [[translator/ext2fs]] root file system in +the *main* Hurd. + +For this, you need to get a handle to the main Hurd's [[ext2fs +translator|translator/ext2fs]]'s [[PID]], but this is no problem, as currently +[[PID]]s are visible across subhurd boundaries. (It is a [[!taglink +open_issue_hurd]] whether this is the right thing to do in +[[open_issues/virtualization]] contexts, but that's how it currently is.) -- cgit v1.2.3 From cfccdc1bdbee7fb25ef0aa9639a3ffec926bf690 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 13 Dec 2010 19:56:25 +0100 Subject: Shuffle / create / enhance some UNIX / glibc pages. --- glibc.mdwn | 8 ++++++-- glibc/environment_variable.mdwn | 15 +++++++++++++++ glibc/environment_variables.mdwn | 15 --------------- glibc/file_descriptor.mdwn | 13 +++++++++++++ glibc/process.mdwn | 26 ++++++++++++++++++++++++++ glibc/signal.mdwn | 31 +++++++++++++++++++++++++++++++ glibc/signals.mdwn | 32 -------------------------------- hurd/glibc.mdwn | 8 +++----- hurd/glibc/internals.mdwn | 35 ----------------------------------- hurd/io_path.mdwn | 4 ++++ naming_context.mdwn | 17 ++++++++++++----- unix.mdwn | 13 ++++++++++++- unix/file_descriptor.mdwn | 4 ++++ unix/process.mdwn | 20 ++++++++++++++++++++ unix/signal.mdwn | 34 ++++++++++++++++++++++++++++++++++ 15 files changed, 180 insertions(+), 95 deletions(-) create mode 100644 glibc/environment_variable.mdwn delete mode 100644 glibc/environment_variables.mdwn create mode 100644 glibc/file_descriptor.mdwn create mode 100644 glibc/process.mdwn create mode 100644 glibc/signal.mdwn delete mode 100644 glibc/signals.mdwn delete mode 100644 hurd/glibc/internals.mdwn create mode 100644 unix/process.mdwn create mode 100644 unix/signal.mdwn (limited to 'hurd') diff --git a/glibc.mdwn b/glibc.mdwn index 124216d9..c47f3f1f 100644 --- a/glibc.mdwn +++ b/glibc.mdwn @@ -38,9 +38,13 @@ Porting glibc to a specific architecture is non-trivial. ## Concepts - * [[environment_variables]] + * [[environment_variable]] - * [[signals]] + * [[file_descriptor]] + + * [[process]] + + * [[signal]] ## Individual functions diff --git a/glibc/environment_variable.mdwn b/glibc/environment_variable.mdwn new file mode 100644 index 00000000..76c1371e --- /dev/null +++ b/glibc/environment_variable.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + +# External + + * [*putenv() and setenv()*](http://www.greenend.org.uk/rjk/2008/putenv.html) + by Richard Kettlewell. diff --git a/glibc/environment_variables.mdwn b/glibc/environment_variables.mdwn deleted file mode 100644 index 76c1371e..00000000 --- a/glibc/environment_variables.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - - -# External - - * [*putenv() and setenv()*](http://www.greenend.org.uk/rjk/2008/putenv.html) - by Richard Kettlewell. diff --git a/glibc/file_descriptor.mdwn b/glibc/file_descriptor.mdwn new file mode 100644 index 00000000..2c56d070 --- /dev/null +++ b/glibc/file_descriptor.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A [[UNIX file descriptor|unix/file_descriptor]] is implemented in [[glibc]] by +using operations on objects referred to by [[Mach +ports|microkernel/mach/port]]). diff --git a/glibc/process.mdwn b/glibc/process.mdwn new file mode 100644 index 00000000..9b2ec251 --- /dev/null +++ b/glibc/process.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The GNU Hurd uses a similar concept to [[UNIX processes|unix/process]]. + +As a [[Mach task|microkernel/mach/task]] only implements a part of a UNIX +process, there is additional work to be done, for example for [[signal]]s, +[[environment_variable]]s, [[file_descriptor]]s. + + +# Controlling TTY + +Hurd controlling tty behavior is generally consistent with BSD's, including +`TIOCSCTTY`. Linux also has `TIOCSCTTY` and it is harmless to use it there. +But BSD and Hurd never do an implicit `TIOCSCTTY` (hence our `O_NOCTTY` is +zero). + +C.f. and the +following messages. diff --git a/glibc/signal.mdwn b/glibc/signal.mdwn new file mode 100644 index 00000000..67028fef --- /dev/null +++ b/glibc/signal.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +The [[*UNIX signalling mechanism*|unix/signal]] is implemented for the GNU Hurd +by means of a separate *signal-handling [[thread]]* that is part of every +[[process]]. This makes handling of signals a separate thread of control. + + * [[SA_SIGINFO, SA_SIGACTION|open_issues/sa_siginfo_sa_sigaction]] + + * Why does `kill` hang sometimes? + + kill send the signal to the process + if the process is hung, killing waits + signals should be just asynchronous, but apparently for some + reason Roland & co wanted some synchronization + + [[!taglink open_issue_glibc]] + + +# Further Reading + + * {{$unix#djb_self-pipe}}. + + * {{$unix#rjk_fork}}. diff --git a/glibc/signals.mdwn b/glibc/signals.mdwn deleted file mode 100644 index 40fdc0e1..00000000 --- a/glibc/signals.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -*[[UNIX]] signals* are a means to asynchronously invoke a specific function -(*signal handler*). This may impact on [[system call]]s that are executing at -the same time in that they may be completely aborted, return incomplete -results, scheduled for restarting, or cause signal delivery to be blocked upon -the system call's completion. - -An explanation can be found in the relevant standards, an overview, including -UNIX signals' deficiencies is given in {{$unix#2010_brown_ghosts_3}}, for -example. - -The UNIX signalling mechanism is implemented for the GNU Hurd by means of a -separate signal-handling thread that is part of every process. This makes -handling of signals a separate thread of control. - - * [[SA_SIGINFO, SA_SIGACTION|open_issues/sa_siginfo_sa_sigaction]] - - -# External - - * {{$unix#djb_self-pipe}}. - - * {{$unix#rjk_fork}}. diff --git a/hurd/glibc.mdwn b/hurd/glibc.mdwn index bdfed833..39bfed62 100644 --- a/hurd/glibc.mdwn +++ b/hurd/glibc.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[General_information|/glibc]] about the glibc. @@ -17,5 +17,3 @@ For information about how the glibc integrates into the system, see sections [[Hurd-specific_API]]. [[Debugging_glibc|debugging/glibc]]. - -[[Internals]]. diff --git a/hurd/glibc/internals.mdwn b/hurd/glibc/internals.mdwn deleted file mode 100644 index 897da92e..00000000 --- a/hurd/glibc/internals.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -[[!meta copyright="Copyright © 2009 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]]."]]"""]] - -Some bits about this, some bits about that. - -# Controlling TTY - -Hurd controlling tty behavior is generally consistent with BSD's, including -`TIOCSCTTY`. Linux also has `TIOCSCTTY` and it is harmless to use it there. -But BSD and Hurd never do an implicit `TIOCSCTTY` (hence our `O_NOCTTY` is -zero). - -C.f. and the -following messages. - -# Sinals - -[[Unix]] signals are implemented in glibc. - -In every process, signals are handled in a separate signal thread. - - [Why does kill hang sometimes?] - kill send the signal to the process - if the process is hung, killing waits - signals should be just asynchronous, but apparently for some reason - Roland & co wanted some syunchronization - -[[!taglink open_issue_glibc]] diff --git a/hurd/io_path.mdwn b/hurd/io_path.mdwn index 598ad967..0d83a4ba 100644 --- a/hurd/io_path.mdwn +++ b/hurd/io_path.mdwn @@ -50,3 +50,7 @@ License|/fdl]]."]]"""]] nice overview of the related layering inside the Linux kernel, including the VFS layer, page cache and directory entry cache (dcache). + + +[[!tag open_issue_documentation]] diff --git a/naming_context.mdwn b/naming_context.mdwn index 3a0751c0..2968b0a5 100644 --- a/naming_context.mdwn +++ b/naming_context.mdwn @@ -1,18 +1,22 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Names are bindings to objects, however, to find an object given a name, the relation must be looked up in a -naming context. A problem with using string as names is +*naming context*. + +A problem with using strings as names is that it is very easy to lose track of the correct naming -context. This is one of the problem with [[PassiveTranslators]]: +context. This is one of the problem with [[passive +translators|hurd/translator]]: a passive translator is a string. When the node is accessed on which the passive translator is set and there is no active translator, then an active translator is started using the @@ -22,3 +26,6 @@ passive translator. The passive translator settings are therefore resolved in the file system's naming context, which may be different from that of the program instance that set the passive translator setting. + +[[!tag open_issue_hurd open_issue_documentation]] diff --git a/unix.mdwn b/unix.mdwn index 3cfe7771..8694f7b0 100644 --- a/unix.mdwn +++ b/unix.mdwn @@ -13,6 +13,17 @@ License|/fdl]]."]]"""]] *UNIX* is a [[kernel]] implementation. +# Concepts + + * [[file_descriptor]] + + * [[process]] + + * [[signal]] + + * [[system_call]] + + # External * Wikipedia page about [[!wikipedia UNIX]]. @@ -31,7 +42,7 @@ License|/fdl]]."]]"""]] to the `open` [[system_call]]. In {{$2010_brown_ghosts_3}}, he deals with *unfixable designs*, such as - [[UNIX signals|glibc/signals]] and the *UNIX permission model* (which is + UNIX [[signal]]s and the *UNIX permission model* (which is clearly inferior to a [[capability]]-based system). * [*UNIX File Permissions*](http://www.greenend.org.uk/rjk/2004/perms.html) diff --git a/unix/file_descriptor.mdwn b/unix/file_descriptor.mdwn index 16e03fdf..6f8533c5 100644 --- a/unix/file_descriptor.mdwn +++ b/unix/file_descriptor.mdwn @@ -11,3 +11,7 @@ License|/fdl]]."]]"""]] A *file descriptor* is a [[concept]] of [[UNIX]], and represents a non-[[persistent|persistency]] handle to an object (a file, for example). With respect to specific aspects, it is comparable to a [[capability]]. + +In a GNU Hurd system, the concept of file descriptors is based on object +handles (through [[Mach ports|microkernel/mach/port]]), and is [[implemented in +glibc|glibc/file_descriptor]]. diff --git a/unix/process.mdwn b/unix/process.mdwn new file mode 100644 index 00000000..21fbfc69 --- /dev/null +++ b/unix/process.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A *UNIX process* is TODO. + +Generally, especially in [[microkernel]]-based systems, the [[kernel]]'s idea +of a task is not as encompassing as a UNIX process, and will use additional +effort to enhance the kernel's primitive to a full-fledged UNIX model. + +A [[Mach task|microkernel/mach/task]] implements a part of a UNIX process. + +In the GNU/Hurd, processes are based on [[Mach task|microkernel/mach/task]]s, +but are [[enhanced by the glibc|glibc/process]]. diff --git a/unix/signal.mdwn b/unix/signal.mdwn new file mode 100644 index 00000000..0d038a45 --- /dev/null +++ b/unix/signal.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*[[UNIX]] signals* are a means to asynchronously invoke a specific function +(*signal handler*) in a [[process]]. It's a rather limited for of doing +[[IPC]]. + +Signalling may impact on [[system call]]s that are executing at the same time +in that they may be completely aborted, return incomplete results, scheduled +for restarting, or cause signal delivery to be blocked upon the system call's +completion. + +An explanation can be found in the relevant standards, an overview, including +UNIX signals' deficiencies is given in {{$unix#2010_brown_ghosts_3}}, for +example. + +In a GNU/Hurd system, the signalling system is [[implemented in +glibc|glibc/signal]]. + + +# Further Reading + + * [[!wikipedia Signal_(computing)]] + + * {{$unix#djb_self-pipe}}. + + * {{$unix#rjk_fork}}. -- cgit v1.2.3 From 4eea3efc13acccfb613571f604f17e0ec68e5bed Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 13 Dec 2010 20:22:52 +0100 Subject: ``Some'' Mach documentation. Parts have been rescued from 4b382d8daa5a9e2d54e78c18beeff76bc54dc16b:Mach/MachConcepts.mdwn. --- hurd/faq/old_hurd_faq.txt | 2 +- idl.mdwn | 22 +++-- ipc.mdwn | 15 ++-- microkernel/fud.mdwn | 14 ++- microkernel/mach/concepts.mdwn | 27 +++++- microkernel/mach/documentation.mdwn | 6 +- microkernel/mach/external_pager_mechanism.mdwn | 14 ++- microkernel/mach/ipc.mdwn | 19 ++--- microkernel/mach/memory_object.mdwn | 31 +++++++ microkernel/mach/message.mdwn | 31 +++++++ microkernel/mach/mig.mdwn | 33 ++++--- microkernel/mach/mig/documentation.mdwn | 14 +-- microkernel/mach/mig/gnu_mig.mdwn | 12 ++- microkernel/mach/port.mdwn | 114 +++++++++++++++++-------- microkernel/mach/rpc.mdwn | 16 ++-- microkernel/mach/task.mdwn | 23 +++++ microkernel/mach/thread.mdwn | 37 ++++++++ microkernel/mach/virtual_address_space.mdwn | 36 ++++++++ 18 files changed, 364 insertions(+), 102 deletions(-) create mode 100644 microkernel/mach/memory_object.mdwn create mode 100644 microkernel/mach/message.mdwn create mode 100644 microkernel/mach/task.mdwn create mode 100644 microkernel/mach/thread.mdwn create mode 100644 microkernel/mach/virtual_address_space.mdwn (limited to 'hurd') diff --git a/hurd/faq/old_hurd_faq.txt b/hurd/faq/old_hurd_faq.txt index c7e0ffe8..e6c6cb5a 100644 --- a/hurd/faq/old_hurd_faq.txt +++ b/hurd/faq/old_hurd_faq.txt @@ -89,7 +89,7 @@ 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, +systems, such as memory management, inter-process 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", diff --git a/idl.mdwn b/idl.mdwn index db58f789..adfd9b93 100644 --- a/idl.mdwn +++ b/idl.mdwn @@ -1,15 +1,19 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -An IDL is an interface definition language. The most well-known is -CORBA. An IDL compiler takes a specification and generates stubs -that hide the transport details. In the case of [[microkernel/mach/MIG]], this -hides the marshalling and unmarshalling of parameters according -to [[microkernel/Mach]]'s semantics. +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +An *IDL* is an *interface definition language*. The most well-known is CORBA. + +An IDL compiler takes a specification and generates stub code that hides the +transport details, and by this implements a [[RPC]] system. + +In the case of [[Mach's MIG|microkernel/mach/mig]], this hides the marshalling +and unmarshalling of parameters according to [[microkernel/Mach]]'s semantics, +and invoking the respective [[microkernel/mach/port]] operations. diff --git a/ipc.mdwn b/ipc.mdwn index 2f9cef2e..ff9a166c 100644 --- a/ipc.mdwn +++ b/ipc.mdwn @@ -1,16 +1,17 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -IPC stands for interprocess communication. +*IPC* stands for *inter-process communication*. -On [[Unix]], interprocess communication can be achieved using pipes. +On [[Unix]], inter-process communication can be achieved using pipes. This is inefficient for large amounts of data as the data must be copied. This is generally not a problem as most services are provided by the Unix kernel and Unix is not designed to be @@ -22,12 +23,14 @@ of many components. As components are separated by their respective examine and modify the caller's state. The advantage is that if the protocol is carefully designed, the callee cannot cause the caller any [[destructive_interference]] thereby removing the need for the -caller to [[trust]] the callee thus reducing the former's [[tcb]]. +caller to [[trust]] the callee thus reducing the former's [[TCB]]. When done systematically, this can increase the system's [[robustness]]. To this end, microkernels provide richer IPC semantics that include the ability to transfer [[capabilities|capability]] and to use [[virtual_memory]] [[mechanism]]s to copy data. +Continue reading about [[Mach's IPC system|microkernel/mach/IPC]]. + # See Also diff --git a/microkernel/fud.mdwn b/microkernel/fud.mdwn index 6353f81d..3f9229aa 100644 --- a/microkernel/fud.mdwn +++ b/microkernel/fud.mdwn @@ -11,7 +11,19 @@ This article is a response to an [earlier article](http://www.linuxjournal.com/n Miles Nordin claimed that microkernels are dead already. But this is not completely true. The first generation of microkernels, which were in fact no real microkernels, are dead. But there is a new generation, which uses a radically different strategy than the original (so-called) microkernels. Thus, microkernels are still a research topic, and today they look more promising than ever before. By now, this is just something we claim, but read on, and you'll find out why we do so. -Out of our own experience, we can confirm that the first generation microkernel Mach is quite slow, but being microkernel independent is one of the goals of the Hurd and people are already working on porting the Hurd from Mach to the second generation microkernel L4. Those new second generation kernels aren't as slow as Mach and we think that one should not talk about the performance of microkernel based systems without having read at least some of the papers on L4. The L4 people did some interesting benchmarks, which indicate that one can get a lot of performance by making a microkernel really small. How is this supposed to work? Well, the microkernel provides very primitive, highly optimized operations, and applications use them to implement whichever way of interprocess communication is apropriate for them in an efficient way. By deciding this on a per-case basis, you get optimal performance for all applications. +Out of our own experience, we can confirm that the first generation microkernel +Mach is quite slow, but being microkernel independent is one of the goals of +the Hurd and people are already working on porting the Hurd from Mach to the +second generation microkernel L4. Those new second generation kernels aren't +as slow as Mach and we think that one should not talk about the performance of +microkernel based systems without having read at least some of the papers on +L4. The L4 people did some interesting benchmarks, which indicate that one can +get a lot of performance by making a microkernel really small. How is this +supposed to work? Well, the microkernel provides very primitive, highly +optimized operations, and applications use them to implement whichever way of +inter-process communication is apropriate for them in an efficient way. By +deciding this on a per-case basis, you get optimal performance for all +applications. But L4 takes this even further. For example, you can have schedulers in userspace. Therefore you can use a scheduler which is optimized for the specific tasks your system performs. With the Linux kernel, different schedulers are only possible by using a different source tree, thus you cannot switch at run-time and/or have different schedulers for different groups of processes. diff --git a/microkernel/mach/concepts.mdwn b/microkernel/mach/concepts.mdwn index 04dbb1c6..a9e8897d 100644 --- a/microkernel/mach/concepts.mdwn +++ b/microkernel/mach/concepts.mdwn @@ -1,6 +1,25 @@ -[[Mach]] is a first-generation [[microkernel]]. Mach's basic abstractions -include [[address_space]]s in the form of [[task]]s, execution contexts in the -form of [[thread]]s, [[IPC]], [[capabilities|capability]] in the form of [[port]]s, and -[[memory_object]]s, which enable Mach's [[external_pager_mechanism]]. +[[!meta copyright="Copyright © 2002, 2003, 2007, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[Mach]] is a first-generation [[microkernel]]. + +Mach's basic abstractions include [[virtual_address_space]]s in the form of +[[task]]s, execution contexts in the form of [[thread]]s, [[IPC]], +[[capabilities|capability]] in the form of [[port]]s, and [[memory_object]]s, +which enable Mach's [[external_pager_mechanism]]. + +Controlling [[task]]s, their [[virtual_address_space]], [[thread]]s, and other +system objects in Mach is implemented by using [[port]]s, as opposed to other +[[kernel]]s' [[system_call]] interface: almost all of the Mach API is +implemented by sending [[message]]s to [[port]]s. Device drivers that reside +in kernel space are controlled by ports, too. Mach's [[API]] is well-[[documented|documentation]]. diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn index fc6e59c2..4c6702aa 100644 --- a/microkernel/mach/documentation.mdwn +++ b/microkernel/mach/documentation.mdwn @@ -6,8 +6,10 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + * Mach's [[concepts]]. * [*Meet Mach* by James Scott](http://beefchunk.com/documentation/macosx-programming/Meet_Mach.pdf), diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn index 2040f4ba..e169495a 100644 --- a/microkernel/mach/external_pager_mechanism.mdwn +++ b/microkernel/mach/external_pager_mechanism.mdwn @@ -9,18 +9,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]]."]]"""]] -Mach provides a so-called external pager [[mechanism]]. This +Mach provides a so-called *external pager [[mechanism]]*. This mechanism serves to separate *managing memory* from *managing -content*. Mach does the former while [[user_space]] [[task]]s do the +content*. Mach does the former while user-space processes do the latter. # Introduction -In Mach, a [[task]]'s [[address_space]] consists of references -to [[memory_object]]s. A memory object is [[designated|designation]] using -a [[port]] (a port is just a [[capability]]) and -implemented by a normal [[process]]. +In Mach, a [[task]]'s [[virtual_address_space]] consists of references to +[[memory_object]]s. To associate a memory object with a portion of a task's address space, `vm_map` is invoked on a capability designating @@ -29,7 +27,7 @@ and the offset at which to install it. (The first time a task maps an object, Mach sends an initialization message to the server including a control capability, which it uses to supply pages to the kernel.) This is essentially -the same as mapping a file into an address space on [[Unix]] +the same as mapping a file into an address space on [[UNIX]] using `mmap`. When a task [[faults|page_fault]], Mach checks to see if there is a memory @@ -86,7 +84,7 @@ structures to manage the mapping and then invokes the mappings in the client's address space and then replies to the `vm_map` RPC indicating success. -There is nothing stopping others from playing "the kernel." This is +There is nothing stopping others from playing *the kernel*. This is not a security problem: clients must [[trust]] the server from whom they obtain memory objects and also the servers with whom they share the object. Multiple memory managers are a reality that should be diff --git a/microkernel/mach/ipc.mdwn b/microkernel/mach/ipc.mdwn index aaf3ba23..1bb44b59 100644 --- a/microkernel/mach/ipc.mdwn +++ b/microkernel/mach/ipc.mdwn @@ -1,22 +1,21 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[General_information|/ipc]] about IPC. +Read about the [[general concept of *inter-process communication* (IPC)|/ipc]]. -An IPC is sent by invoking a [[port]]. +On Mach, an IPC is done by invoking a [[port]]. + +The two fundamental operations, to *send* and *receive* [[message]]s, are used +to implement a [[RPC]] system. [[Sequence_numbering]]. [The Unofficial GNU Mach IPC beginner's guide](http://www.nongnu.org/hurdextras/ipc_guide/ipc_guide.html) - -# See Also - -* [[RPC]] diff --git a/microkernel/mach/memory_object.mdwn b/microkernel/mach/memory_object.mdwn new file mode 100644 index 00000000..2342145c --- /dev/null +++ b/microkernel/mach/memory_object.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Mach's [[virtual_memory]] subsystem uses *memory objects* for supplying the +content of regions of virtual memory in an [[virtual_address_space]]. + +All of these objects are managed by *memory manager*s, that are also called +*pager*s. These can be implemented as user-space processes. + +Both the memory objects, and their managers are kernel objects, and are +accessed by [[port]]s. + +A system's physical memory is conceived as a *memory cache* that contains +*memory cache objects*. So when a [[thread]] accesses a page in its task's +address space, the memory object that includes this page is *cached* in the +memory cache. Memory objects are [[paged out and paged +in|external_pager_mechanism]] by the aforementioned memory managers. The +decision when they should be paged in or paged out is left to [[Mach]]. Each +memory object has an ordered list of memory managers that provide paging. The +last one tried is the *default memory manager* that resides in the microkernel, +in contrast to most of the others. The default memory manager is needed +because the microkernel can't wait infinitely for someone else to free the +memory cache: it just calls the next memory manager hoping it to succeed. diff --git a/microkernel/mach/message.mdwn b/microkernel/mach/message.mdwn new file mode 100644 index 00000000..ba47671e --- /dev/null +++ b/microkernel/mach/message.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*Messages* are collections of typed data, with a defined layout. + +They are used for [[IPC]], and are sent to and received from [[port]]s. + +These messages are not only opaque data. They can also contain [[port +rights|port]] to be passed to another [[task]]. Port rights are either +*copied* or *moved*. Notice that port receive right must be moved but not +copied because there can't be more than one task that holds the receive right +to a port. The receiving task creates new local port name to the port rights +it received. + +Some data in the message can be *out-of-line data*. In the message, these are +*references* to memory regions ([[memory_object]]s) that are *virtually +copied*. When the message is received in a task, these virtual copies become +part of the task by mapping them into the receiver's [[virtual_address_space]]. +Another key concept that is applied is using *copy-on-write*, which means that +data is not copied immediately, but only when it is changed. This is primarily +used to send large blocks of data efficiently, as it is too expensive to store +them in the kernel address space: extra copied need only be made at the moment +that the memory regions begin to diverge, by threads modifying them. diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn index 4275a4b4..331b3bf4 100644 --- a/microkernel/mach/mig.mdwn +++ b/microkernel/mach/mig.mdwn @@ -1,21 +1,34 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2006, 2007, 2008 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2001, 2002, 2003, 2006, 2007, 2008, 2010 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -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 and make it easy to implement -and use Mach [[interface]]s as [[remote_procedure_calls_(RPC)|rpc]]. +The *Mach Interface Generator* (*MIG*) is an [[IDL]] compiler. Based on an +interface definition, it creates stub code to [[invoke]] object methods and to +demultiplex incoming messages. These stub functions conveniently hide the +details of Mach's [[IPC]] and [[port]] machinery and make it easy to implement +and use Mach [[interface]]s as [[remote procedure calls (RPC)|rpc]]: by using +the stub functions, the client programs can call remote procedures more or less +like any other C function. + +These functions encode arguments into [[message]]s' format (*marshalling*), +wait for a result on a newly created [[reply port|port]], decode return +arguments from the reply message (*demarshalling*, or *unmarshalling*) and pass +them to the client program. Similar actions are provided in the skeletons that +are linked to server programs. + +MIG allows very precise semantics to be specified about what the arguments are +and how to be passed. + + + * [[Documentation]] -* [[Documentation]] # Implementations diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index be762960..7d4f1eca 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] This is a small collection of links to external documents describing the *Mach Interface Generator* used by GNU Mach. @@ -17,7 +17,7 @@ Interface Generator* used by GNU Mach. A tutorial which demonstrates the use of the C Threads library primitives in writing a multithreaded program and the use of the Mach Interface Generator -(MIG) to generate remote procedure calls for interprocess communication. Like +(MIG) to generate remote procedure calls for inter-process communication. Like its companion tutorial, it is based on the Mach 2.5 system. However, the concepts are applicable to Mach 3.0 user level programming. @@ -41,9 +41,9 @@ Slides to Rich Drave's talk on MIG, on November 21, 1991: Mig is an implementation of a subset of the Matchmaker **language**. "Matchmaker is a language for specifying and automating the generation of -multilingual interprocess communication interfaces. MIG is an interim +multilingual inter-process communication interfaces. MIG is an interim implementation of a subset of the Matchmaker language that generates C and C++ -remote procedure call interfaces for interprocess communication between Mach +remote procedure call interfaces for inter-process communication between Mach tasks." Richard P. Draves, Michael B. Jones, Mary R. Thompson, *MIG - THE MACH diff --git a/microkernel/mach/mig/gnu_mig.mdwn b/microkernel/mach/mig/gnu_mig.mdwn index 1bcbd545..0de1bd67 100644 --- a/microkernel/mach/mig/gnu_mig.mdwn +++ b/microkernel/mach/mig/gnu_mig.mdwn @@ -1,13 +1,13 @@ -[[!meta copyright="Copyright © 2001, 2006, 2008, 2009 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2001, 2006, 2008, 2009, 2010 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +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 @@ -20,5 +20,9 @@ software in the GNU system that uses Mach-based GNU MIG is fully compatible with [[OSF_MIG|mig]]. +Like its predecessor, it can only generate C code, that has to be compiled and +linked to client and server programs respectively ([[!taglink +open_issue_mig]]). + * [[Building]] - building (and obtaining) GNU MIG * [[Open Issues|tag/open_issue_mig]] diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn index af4a0c8d..ba2e22c2 100644 --- a/microkernel/mach/port.mdwn +++ b/microkernel/mach/port.mdwn @@ -1,41 +1,85 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] - -Mach ports are [[capabilities|capability]]. - -A Mach port is a kernel queue. Each port has associated with -it a receive right and one or more send and send-once rights. -A queue can hold a number of messages. Once the queue is full, -the send blocks until their is space to enqueue the message -(this is interruptible via a timeout mechanism). - -A receive right designates a queue and authorizes the holder to -dequeue messages from the queue, and to create send and send-once -rights. - -Send and send-once rights designate a queue and authorize the -hold to enqueue messages (in the case of a send-once right, -a single message). Enqueuing a message is equivalent to -[[invoke|invoking]] a capability. - -Send and receive rights are named using local names. Each -task has associated with it a port [[address_space]]. A ports -are addressed via this table. Each task thus has its own -private [[naming_context]] for ports. - -Ports can be [[delegate]]d in an [[IPC]] message. When the -receiver dequeues the message, the right is made available -to it. - -A [[thread]] can only block receiving on a single port. To work -around this, the concept of a port set was introduced. A receive -right can be added to (at most) one port set. When a thread -receives from a port set, it dequeues from any of the ports that -has a message available. +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[Mach]] *port*s are [[capabilities|capability]], and are also essentially +similar to [[UNIX]] pipes. They are communication channels, implemented by +kernel queues. + +Each port has associated with it one *receive right* and one or more *send +right*s and *send-once right*s. That is, there is one receiver and one or more +senders -- a unidirectional communication channel. Only with the corresponding +port right, access to a port is possible; this is enforced by Mach. + +The kernel queue can hold a number of [[message]]s. Once the queue is full, +the send blocks until there is space to enqueue the message (this is +interruptible via a timeout mechanism). + +A receive right [[designates|designation]] a queue and authorizes the holder to +dequeue messages from the queue, and to create send and send-once rights. + +Send and send-once rights designate a queue and authorize the hold to enqueue +messages (in the case of a send-once right, a single message). Enqueuing a +message is equivalent to [[invoke|invoking]] a capability. + +Ports are automatically destroyed when there is no associated port right to +them. + +Mach knows what port rights belong to each task, but [[thread]]s that running +in the context of a task refer to ports by means of send and receive rights +that are named using local *port names*. These port names are plain integers, +like [[UNIX file descriptors|unix/file_descriptor]]. Only these local names +can be used by [[thread]]s for invoking operations on ports, threads do not +deal with port rights directly. + +For that, each task has associated with it a *port address_space*, or *port +name space*. All ports are addressed via this table. Each task thus has its +own private [[naming_context]] for port rights. + +So, the picture is that after obtaining a port send right, the client uses a +port name to send [[message]]s to the port, or exactly one message if it's a +send-once right. These messages are (probably) queued and when the server task +tries to receive messages by having a [[thread]] use its port receive right, it +gets the message(s). This is called [[IPC]]. + +Port rights themselvse can be [[delegate]]d in a [[message]], too. When the +receiver dequeues the message, the right is made available to it. + +The delivery of [[message]]s is reliable and strictly ordered. When a +[[thread]] sends messages *1* and *2*, it is guaranteed that the receiving +[[task]] will catch them in the same order. Of course, there can be +intermediate messages that are sent by other threads. + +Ports are objects that are implemented by the [[kernel]], and they are +kernel-protected resources. There is no way for a [[task]] to do anything with +a port unless it have corresponding port right. + +Due to this, ports are globally unique. This makes them ideal for constituting +system-wide *object references*. For example, the [[RPC]] system as used by +the GNU Hurd works by invoking *methods* on such object references. The +available methods are defined in [[hurd/interface]] files, and are processes by +the [[MIG]] tool. + +Invoking an operation on a port does not transfer the current execution control +to the receiver, but instead is an asynchronous operation. For this, and +especially in a [[RPC]] system, the sender may include a *reply port* using a +send-once right, and synchronize (block) on that one. + +A [[thread]] can only block receiving on a single port. To work around this, +the concept of a *port set* was introduced. A receive right can be added to +(at most) one port set. These port sets look like port receive rights, but +cannot be passed to other tasks, and there are additional operations for adding +and removing port receive rights. + +When a server process' thread receives from a port set, it dequeues exactly one +message from any of the ports that has a message available in its queue. + +This concept of port sets is also the facility that makes convenient +implementation of [[UNIX]]'s `select` [[system_call]] possible. diff --git a/microkernel/mach/rpc.mdwn b/microkernel/mach/rpc.mdwn index 72acfaa0..60275a86 100644 --- a/microkernel/mach/rpc.mdwn +++ b/microkernel/mach/rpc.mdwn @@ -1,15 +1,21 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[General_information|/rpc]] about RPC. +Read about the [[general concept of a *remote procedure call* (RPC)|/rpc]]. Uses Mach's [[IPC]] [[mechanism]]. -Stub code generated by [[MIG]]. +The [[port]] abstraction allows RPCs to be executed on another computer +transparently. This can be implemented with user [[task]]s, but there is an +implementation in the kernel possible, too, which is called *NORMA*, but is not +avilable in [[GNU Mach|gnumach]]. + +The RPC stub code generated by [[MIG]]. diff --git a/microkernel/mach/task.mdwn b/microkernel/mach/task.mdwn new file mode 100644 index 00000000..c03c6a14 --- /dev/null +++ b/microkernel/mach/task.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A Mach *task* is a collection of resources, a [[virtual_address_space]], and a +[[port name space|port]]. They depend on [[thread]]s for executing program +code: a task alone has no means to do so. + +Switching from one task to another one involves doing a *context switch*, which +is usually not a cheap operation, as it involves switching the hardware's idea +of the memory layout ([[virtual_address_space]]), amongst others. + +Mach tasks are distinct from [[UNIX processes|unix/process]] in that they +provide less facilities. In processes, there are [[unix/signal]]s, process / +group / session IDs, [[unix/file_descriptor]]s and many other things. Tasks +are used for resource allocation and sharing; they are *resource container*s. diff --git a/microkernel/mach/thread.mdwn b/microkernel/mach/thread.mdwn new file mode 100644 index 00000000..e27bb117 --- /dev/null +++ b/microkernel/mach/thread.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +A Mach *thread* belongs to exactly one [[task]], and is the means of execution. +The task supplies the resources. + +Mach threads are implemented inside the [[kernel]], as opposed to other +systems' user-level thread packages. + +A thread (theoretically) runs concurrently with all the other threads of a +system. If the system provides several processors, they can be used for +simultaneously running either several threads of the same task, or several +threads of different tasks. [[!tag open_issue_documentation]] (But this is currently not support in [[GNU +Mach|gnumach]].) + +It is easy for the kernel to switch execution from one thread to another one +inside the same task: essentially, it only involves exchanging a few processor +registers' state. + +Threads have scheduling parameters and maintain various statistics about +themselves. + +On GNU/Hurd, APIs for Mach threads and thereabouts are provided by the +[[hurd/libthreads]] (cthreads), and [[libpthread]] (POSIX Threads) packages. + +A task backing a thread is the basis for a [[UNIX process|unix/process]]. diff --git a/microkernel/mach/virtual_address_space.mdwn b/microkernel/mach/virtual_address_space.mdwn new file mode 100644 index 00000000..97bc5f6b --- /dev/null +++ b/microkernel/mach/virtual_address_space.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +*Virtual address space*s in Mach define the valid virtual addresses that can be +used by [[thread]]s under execution in the [[task]] that owns that address +space. Each task has only one address space and each address space belongs to +only one task. So when we want to name an address space (for example, in the +Mach API) we name it by the task it belongs to. + +These address spaces are divided into *pages*. Each page has individual +properties like *access rights* (*read* / *write* / *execute*), *inheritance +attributes* (*no inheritance* / *copy* / *share*) and some other system +properties. Page manipulation is optimized to help moving large blocks of data +from one address space to another, for example when one thread provides data to +another thread -- *client / server* technology. + +Memory ranges of pages that can be controlled as a whole are called +*[[memory_object]]*s. + +*Wired pages* are those that cannot be [[paged out|external_pager_mechanism]]. +For example, Mach itself is a task with its own address space and threads, and +all of its pages are wired. + +*Precious pages* are those that must not be discarded silently when they are +clean and memory is needed. For example, a memory manager that shares memory +across a network could not restore a page if it is silently discarded because +it is unmodified. This is not valid for the well-known [[pager +managers|external_pager_mechanism]] that use disks as backing store. -- cgit v1.2.3 From 3f0379f2b72c6fd270720e64eeda0a8a34fcb2a8 Mon Sep 17 00:00:00 2001 From: "http://www.barrucadu.co.uk/" Date: Sun, 19 Dec 2010 17:38:03 +0000 Subject: Fixed Allan's name. --- hurd/running/arch_hurd.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/running/arch_hurd.mdwn b/hurd/running/arch_hurd.mdwn index 9786d144..0e6075bb 100644 --- a/hurd/running/arch_hurd.mdwn +++ b/hurd/running/arch_hurd.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!meta title="Arch Hurd"]] -Arch Hurd is a port of Arch Linux to the GNU Hurd, founded on 2010-01-04 by Michael Walker (Barrucadu) and, with input from a variety of people including Alan McRae (allan), Matthias Lanzinger (melpo), and Alexander Preisinger (giselher), the project has made excellent process. There is a livecd available on the Arch Hurd website, with which you can try or install Arch Hurd. +Arch Hurd is a port of Arch Linux to the GNU Hurd, founded on 2010-01-04 by Michael Walker (Barrucadu) and, with input from a variety of people including Allan McRae (allan), Matthias Lanzinger (melpo), and Alexander Preisinger (giselher), the project has made excellent process. There is a livecd available on the Arch Hurd website, with which you can try or install Arch Hurd. ### Links -- cgit v1.2.3 From 29b6f1b8a084c61d2d62d33e2d4413b91afae6e3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 21 Dec 2010 12:43:38 +0100 Subject: faq/posix_compatibility: New. --- advantages.mdwn | 4 ++-- faq/posix_compatibility.mdwn | 32 ++++++++++++++++++++++++++++++++ hurd/interface.mdwn | 4 +++- hurd/status.mdwn | 9 +++++---- 4 files changed, 42 insertions(+), 7 deletions(-) create mode 100644 faq/posix_compatibility.mdwn (limited to 'hurd') diff --git a/advantages.mdwn b/advantages.mdwn index 8b41f3cd..100c8ff8 100644 --- a/advantages.mdwn +++ b/advantages.mdwn @@ -17,8 +17,8 @@ terms of the [[GNU General Public License (GPL)|GPL]]. It's compatible as it provides a familiar programming and user environment. For all intents and purposes, the Hurd provides the same facilities as 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. +development closely tracks [[standards such as ANSI/ISO, BSD, POSIX, Single +Unix, SVID, and X/Open|faq/posix_compatibility]]. Unlike other popular kernel software, the Hurd has an object-oriented structure that allows it to evolve without compromising its design. This structure will diff --git a/faq/posix_compatibility.mdwn b/faq/posix_compatibility.mdwn new file mode 100644 index 00000000..1525a7ad --- /dev/null +++ b/faq/posix_compatibility.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="POSIX compatibility"]] + +Is it favorable of rather a hindrance to be compatible to POSIX and similar +standards? + +A lot of things in POSIX et al. are designed for [[UNIX]]-like systems with +traditional monolithic [[kernel]]s. + +Thus, a [[microkernel]]-based system, as ours is, has to employ a bunch of +detours, for example to implement the [[`fork` system call|glibc/fork]]. + +On the other hand, (mostly) complying to these standards, made a really big +body of software *just work* without any (or just trivial) [[hurd/porting]]. +Especially so for command-line programs, and libraries. + +But: a large part of today's user programs are not written according to POSIX +et al. low-level interfaces, but against GNOME, GTK+2, and other high-level +frameworks and libraries. It may be a valid option to enrich these instead of +striving for total POSIX compliance -- and the high-level programs (that is, +their users) may not even notice this, but we would avoid a lot of overhead +that comes with wrapping the [[Hurd interfaces|hurd/interface]] to be POSIX +compliant. diff --git a/hurd/interface.mdwn b/hurd/interface.mdwn index 75fda808..53cd31f0 100644 --- a/hurd/interface.mdwn +++ b/hurd/interface.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,5 +10,7 @@ License|/fdl]]."]]"""]] [[!meta title="Interfaces"]] +/!\ Incomplete. + [[!map pages="hurd/interface/* and !hurd/interface/*_*" show=title]] diff --git a/hurd/status.mdwn b/hurd/status.mdwn index 721cdeda..fe56f183 100644 --- a/hurd/status.mdwn +++ b/hurd/status.mdwn @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] 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 @@ -30,8 +30,9 @@ 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 +cards) and other hardware is mostly missing. Although the [[POSIX +interface|faq/posix_compatibility]] 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 -- cgit v1.2.3 From 3bbe62327128ce85829a4cb2fb429bd8f21b4d75 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 9 Jan 2011 22:21:40 +0100 Subject: news/2010-12: New. --- hurd/subhurd.mdwn | 1 + hurd/virtualization.mdwn | 10 +++++++--- news/2010-12.mdwn | 45 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 53 insertions(+), 3 deletions(-) create mode 100644 news/2010-12.mdwn (limited to 'hurd') diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index 84372dd1..cb4a40a8 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -125,6 +125,7 @@ Roland's tutorial about [[running_a_subhurd]]. # Use Cases + ## Debugging the *Main* Hurd System A subhurd can be used for debugging the *main* Hurd system. This works as long diff --git a/hurd/virtualization.mdwn b/hurd/virtualization.mdwn index 42f83f77..49e911c2 100644 --- a/hurd/virtualization.mdwn +++ b/hurd/virtualization.mdwn @@ -1,13 +1,17 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2011 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] Olaf Buddenhagen has written a text about how [[/virtualization]] is applicable within Hurd systems: + +We also have [[a lot of Open Issues about virtualization +topics|open_issues/virtualization]]. diff --git a/news/2010-12.mdwn b/news/2010-12.mdwn new file mode 100644 index 00000000..60d0226f --- /dev/null +++ b/news/2010-12.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2011-01-09 21:25 UTC"]] + +A month of the Hurd: *CD images*. +[[!if test="included()" then="""[[!toggle id=full_news +text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]""" +else=" +[[!paste id=full_news]]"]] + +[[!cut id="full_news" text=""" + +Samuel Thibault [*updated the Debian GNU/Hurd installer +ISO*](http://lists.debian.org/debian-hurd/2010/12/msg00001.html), and also +again did his regular batch of bug fixing. + +*Arch Hurd is back in action!*, too: they uploaded a [first version of a +graphical live CD](http://www.archhurd.org/news/19/). + +Neal Walfield +[reported](http://lists.gnu.org/archive/html/l4-hurd/2010-12/msg00001.html) on +the state of his [[microkernel/Viengoos]] kernel / research project, which +unfortunately is currently on hold, due to other commitments. + +Olaf Buddenhagen raised an interesting use case: you can use a [[*subhurd* for +debugging the *main* Hurd system|hurd/subhurd#debugging_main_hurd_system]]. +That is [[hurd/virtualization]] at its best! + +Right before the end of the year, Diego Martin Nieto Cid sent a [patch series +to fix some issues with `make +dist`](http://lists.gnu.org/archive/html/bug-hurd/2010-12/msg00024.html). + +--- + +Happy New Year 2011, everyone! + +"""]] -- cgit v1.2.3