Merge branch 'master' of flubber:~hurd-web/hurd-web

8 files changed, 86 insertions, 61 deletions

diff --git a/microkernel/faq.mdwn b/microkernel/faq.mdwn
index a6c4f1f8..aa98403a 100644
--- a/microkernel/faq.mdwn
+++ b/microkernel/faq.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]]
+[[!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
@@ -15,4 +15,4 @@ pages="microkernel/faq/* and !*/discussion"
 show=0
 feeds=no
 actions=yes
-rootpage=microkernel/faq" postformtext="Add a new item titled:"]]
+rootpage="microkernel/faq" postformtext="Add a new item titled:"]]
diff --git a/microkernel/fud.mdwn b/microkernel/fud.mdwn
index eef829e0..6353f81d 100644
--- a/microkernel/fud.mdwn
+++ b/microkernel/fud.mdwn
@@ -17,6 +17,6 @@ But L4 takes this even further. For example, you can have schedulers in userspac
 
 Of course, microkernels still have some problems, mainly because we are bound to today's technology, and current processors have not been designed with microkernels in mind. On a processor that is not optimized for systems with monolithic kernels, where the currently still problematic overhead of context switches would vanish, microkernels would get another performance boost. This sounds like an excuse, but it is intended as a reminder about the fact that the problem is not the general concept of microkernels. However, the L4 people have done a lot of good hacks to work around all this and have reached reasonable performance already.
 
-All this could be discussed in arbitrary detail, but we won't do that now, as we have more urgent things to do than reacting on FUD about microkernels. So we will conclude by saying that it is too easy to claim that one design is fast and the other one is slow, but everything depends on how exactly a system is designed and implemented. Maybe microkernels will eventually turn out to be slower in almost any case; we doubt that, but who knows? But even then, a microkernel based system will offer enough other advantages so that people will prefer to use it in some cases. But on the other hand, history has shown that new concepts seldom replace old ones completely, but rather establish themselfes in addition to the old ones, therefore we will have the opportunity to argue about which concept is best at least for another couple of years.. or decades?
+All this could be discussed in arbitrary detail, but we won't do that now, as we have more urgent things to do than reacting on FUD about microkernels. So we will conclude by saying that it is too easy to claim that one design is fast and the other one is slow, but everything depends on how exactly a system is designed and implemented. Maybe microkernels will eventually turn out to be slower in almost any case; we doubt that, but who knows? But even then, a microkernel based system will offer enough other advantages so that people will prefer to use it in some cases. But on the other hand, history has shown that new concepts seldom replace old ones completely, but rather establish themselves in addition to the old ones, therefore we will have the opportunity to argue about which concept is best at least for another couple of years.. or decades?
 
 If you are interested in research about the performance of microkernel based systems, visit <http://www.l4ka.org> and <http://os.inf.tu-dresden.de/L4/>
diff --git a/microkernel/mach/history.mdwn b/microkernel/mach/history.mdwn
index a8951737..5a3608cd 100644
--- a/microkernel/mach/history.mdwn
+++ b/microkernel/mach/history.mdwn
@@ -1,7 +1,3 @@
-# <a name="Table_of_Contents"> Table of Contents </a>
-
-%TOC%
-
 # <a name="Early_beginnings"> Early beginnings </a>
 
 Mach has quite a history. Everything actually started at the University of Rochester in 1975. It was invented to demonstrate how operating systems could be built using a modular design where processes communicated using message passing, even across networks. The system was called the Rochester Intelligent Gateway and ran on a 16 bit mini computer called Eclipse from Data General.
diff --git a/microkernel/viengoos.mdwn b/microkernel/viengoos.mdwn
index d4edc929..2b9fee03 100644
--- a/microkernel/viengoos.mdwn
+++ b/microkernel/viengoos.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]]
+[[!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
@@ -24,6 +24,8 @@ Then update to viengoos-on-bare-metal
 
 viengoos-on-bare-metal is the current development focus.
 
+Discussion should be held on the [[mailing lists/l4-hurd]] mailing list.
+
   * [[Building]]
   * Running
       * [[QEMU]]
diff --git a/microkernel/viengoos/projects.mdwn b/microkernel/viengoos/projects.mdwn
index 27dcc3e2..971206bb 100644
--- a/microkernel/viengoos/projects.mdwn
+++ b/microkernel/viengoos/projects.mdwn
@@ -8,58 +8,10 @@ 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_viengoos]]
-
 Some projects:
 
-# Minor
-
-## New hash function
-
-The current hash function in libhurd-ihash results in a lot of
-collisions when the hash table is 80% full.  To overcome this, we keep
-hash tables at most 30% full.  This represents a fair amount of
-overhead.  Find a better algorithm.  There can either be one that is
-appropriate in the general case or one that works well in a relevant,
-specific case, e.g., viengoos/object.c uses a hash to find the object
-corresponding to a frame, which is keyed on its physical address.
-
-# Major
-
-## Address Space Management
-
-In Viengoos, a process's address space is managed entirely in user
-space by the process itself.  This creates two interesting problems:
-dealing with circular dependencies resulting from having to manage the
-address space data structures and accessing and manipulating the
-address space data structures.
-
-First, managing the address space requires resources, which in turn
-may require address space (e.g., data structures require memory which
-require address space, etc.).  We currently break this circular
-dependency by trying to keep enough resources in reserve that
-allocating resources for managing the address space never requires
-more resources than are minimally in the reserve.  The reserve is
-currently chosen in an ad-hoc fashion.  It would be nice to determine
-it more systematically.  Moreover, it would be nice to reduce the
-cases in which a reserve is required.  This may be possible by
-restructuring some of the code.
-
-Second, the address space data structures are protected using a single
-lock.  This not only means that only a single thread can be updating
-the address space at a time, but that if a thread faults and the
-address space is locked, then the process dead locks!  It should be
-possible to at least walk the address space using lock-free
-techniques.  This requires updating the address space construction
-code such that all addresses remain valid during any given
-manipulation.  Second, to avoid the mentioned dead-lock problem, we
-try to ensure that accessing the data structures will never result in
-a fault.  This means protecting the stack.  An alternative approach is
-to use undo buffers.
-
-# Thesis
-
-## Capability aware compiler
-
-Modify, e.g., gcc to understand capability semantics and teach gcc how
-to optimize it, e.g., how to batch and combine calls.
+[[!inline
+pages="microkernel/viengoos/projects/* and !microkernel/viengoos/projects/*/*"
+show=0
+feeds=no
+actions=yes]]
diff --git a/microkernel/viengoos/projects/address_space_management.mdwn b/microkernel/viengoos/projects/address_space_management.mdwn
new file mode 100644
index 00000000..2d00e4f4
--- /dev/null
+++ b/microkernel/viengoos/projects/address_space_management.mdwn
@@ -0,0 +1,40 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_viengoos]]
+
+In Viengoos, a process's address space is managed entirely in user
+space by the process itself.  This creates two interesting problems:
+dealing with circular dependencies resulting from having to manage the
+address space data structures and accessing and manipulating the
+address space data structures.
+
+First, managing the address space requires resources, which in turn
+may require address space (e.g., data structures require memory which
+require address space, etc.).  We currently break this circular
+dependency by trying to keep enough resources in reserve that
+allocating resources for managing the address space never requires
+more resources than are minimally in the reserve.  The reserve is
+currently chosen in an ad-hoc fashion.  It would be nice to determine
+it more systematically.  Moreover, it would be nice to reduce the
+cases in which a reserve is required.  This may be possible by
+restructuring some of the code.
+
+Second, the address space data structures are protected using a single
+lock.  This not only means that only a single thread can be updating
+the address space at a time, but that if a thread faults and the
+address space is locked, then the process dead locks!  It should be
+possible to at least walk the address space using lock-free
+techniques.  This requires updating the address space construction
+code such that all addresses remain valid during any given
+manipulation.  Second, to avoid the mentioned dead-lock problem, we
+try to ensure that accessing the data structures will never result in
+a fault.  This means protecting the stack.  An alternative approach is
+to use undo buffers.
diff --git a/microkernel/viengoos/projects/capability-aware_compiler.mdwn b/microkernel/viengoos/projects/capability-aware_compiler.mdwn
new file mode 100644
index 00000000..b4e465d9
--- /dev/null
+++ b/microkernel/viengoos/projects/capability-aware_compiler.mdwn
@@ -0,0 +1,16 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_viengoos]]
+
+Modify, e.g., gcc to understand capability semantics and teach gcc how
+to optimize it, e.g., how to batch and combine calls.
+
+This project is deemed suitable for a thesis.
diff --git a/microkernel/viengoos/projects/new_hash_function.mdwn b/microkernel/viengoos/projects/new_hash_function.mdwn
new file mode 100644
index 00000000..1747511d
--- /dev/null
+++ b/microkernel/viengoos/projects/new_hash_function.mdwn
@@ -0,0 +1,19 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_viengoos]]
+
+The current hash function in libhurd-ihash results in a lot of
+collisions when the hash table is 80% full.  To overcome this, we keep
+hash tables at most 30% full.  This represents a fair amount of
+overhead.  Find a better algorithm.  There can either be one that is
+appropriate in the general case or one that works well in a relevant,
+specific case, e.g., viengoos/object.c uses a hash to find the object
+corresponding to a frame, which is keyed on its physical address.