Merge commit '6ded0f6763c776e42d363f2b5714c79a34c9b70f'

Polish and enhance some pages some more.

8 files changed, 122 insertions, 16 deletions

diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index d235570f..5a274cc5 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -83,10 +83,12 @@ other: language_bindings, gccgo, perl_python.  -->
 [[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]]
+[[!inline pages="community/gsoc/project_ideas/object_lookups" show=0 feeds=no actions=yes]]
 [[!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/smp" show=0 feeds=no actions=yes]]
+<!-- Richard, This task actually looks too big for a GSoC project.
+[[!inline pages="community/gsoc/project_ideas/smp" show=0 feeds=no actions=yes]] -->
 [[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/vm_tuning" show=0 feeds=no actions=yes]]
diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn
new file mode 100644
index 00000000..462f6a12
--- /dev/null
+++ b/community/gsoc/project_ideas/object_lookups.mdwn
@@ -0,0 +1,42 @@
+[[!meta copyright="Copyright © 2013 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="Improved system object lookups"]]
+
+The Hurd currently uses its ihash library ([[hurd/libihash]]) as a generic
+container for various objects. While it does its job, it has been reported
+to suffer from high collision rates. In addition, the "one size fits all"
+approach contributes to slow things down. One particular use case is looking
+up an object from a Mach port name, which basically translates to getting the
+file or socket associated with a file descriptor in traditional Unix systems.
+It's particular because there are actually two lookups for each object, the
+first being finding the Mach port from a client port name, which is done in
+the GNU Mach kernel, and the second being finding the server object from a
+server port name. The best strategy would probably be to directly associate
+the address of an object to the receive right of its port, eliminating the
+need to look up again, but this is quite an intrusive change in the code base.
+For the time being, optimizing lookups would already be an improvement.
+
+The goal of this project is to increase system performance by speeding up
+object lookups, with a particular focus on name-to-object lookups. Note that
+there is little room for improvement in the kernel name-to-port lookups because
+of the various optimizations IPC has received in the past. Looking up server
+objects from port names could use an algorithm highly tuned for this task,
+perhaps with better locking (shared/exclusive instead of always mutually
+exclusive for example). Then, the libihash algorithm could be replaced with a
+better one, not necessarily a hash based one, to improve all the other users.
+
+This task requires proper knowledge of data structure algorithms, taking into
+account machine properties such as processor caches, as well as the appropriate
+skills in C and assembly to check the generated code. Being able to perform
+accurate measurements in a system that lacks modern profiling tools would also
+be helpful.
+
+Possible mentors: Richard Braun
diff --git a/faq/issues/got_a_db_prompt.mdwn b/faq/issues/got_a_db_prompt.mdwn
new file mode 100644
index 00000000..ce376728
--- /dev/null
+++ b/faq/issues/got_a_db_prompt.mdwn
@@ -0,0 +1,34 @@
+[[!meta copyright="Copyright © 2013 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="Help, I've just gotten a db> prompt"]]
+
+If you see a `db>` prompt on the console, something unexpected and bad happened
+inside the [[GNU Mach kernel|microkernel/mach/gnumach]], which it cannot
+recover from.  (Think of it as the equivalent of a [[!wikipedia
+Linux_kernel_oops]], for example.)  The `db>` prompt is actually the GNU Mach
+kernel debugger waiting for your commands.  For example, you can then reboot
+the system by issuing the `reboot` command, or if you want to help analyze the
+problem, start by typing in the `trace` command, which will display the
+function call trace leading to the crash:
+
+    0x8007cf1(8088488,5e,40000008,2aa008,0)
+    0x80071bc(0,0,0,0,0)
+    0x8006831(24fe00,2000,b,800,0)
+
+This can be decyphered by using:
+
+    $ addr2line -i -f -e /boot/gnumach 0x8007cf1 0x80071bc 0x8006831
+
+You can then [[send us|contact_us]] the results of the `trace` and the
+`addr2line` commands, as well as
+the exact version of the GNU Mach kernel you were running, for further
+investigation.  More information about the [[GNU Mach
+debugger|microkernel/mach/gnumach/debugging]] is available.
diff --git a/faq/support/0-drivers.mdwn b/faq/support/0-drivers.mdwn
index 974fb612..54b2d744 100644
--- a/faq/support/0-drivers.mdwn
+++ b/faq/support/0-drivers.mdwn
@@ -15,4 +15,10 @@ Currently, for disks Mach integrates drivers from Linux 2.0 through some
 limits hardware support a lot, of course.  For network boards, we use the
 [[DDE]] toolkit to run linux 2.6.32 drivers in userland processes,
 which provides both long-term support for new hardware and safety against driver
-bugs.
+bugs.  [[microkernel/mach/gnumach/ports/Xen]] is also supported, both blkfront
+and netfront.
+
+Note however that we have of course not tested all drivers, we obviously don't
+even have all kinds of hardware. So we can not promise that they will all
+work. What probably works for sure is what we usually use: the rtl8139 or e1000
+drivers for instance.
diff --git a/faq/support/0-software.mdwn b/faq/support/0-software.mdwn
index 324dbbef..e58e0bd8 100644
--- a/faq/support/0-software.mdwn
+++ b/faq/support/0-software.mdwn
@@ -11,6 +11,16 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="What software is available for GNU?"]]
 
-  * Most (3/4) packages from [Debian](http://www.debian.org/) [GNU/Linux](http://www.gnu.org/gnu/linux-and-gnu.html) which aren't linux-specific ([Packages That Won't Be Ported](http://www.debian.org/ports/hurd/hurd-devel-debian)) are expected to work on GNU/Hurd too. See the database in <http://packages.debian.org/>. Notably, [GNOME](http://www.gnome.org), and [KDE](http://www.kde.org) work. See the [[porting/guidelines]] document for some common build problems and their solutions.
-  * If you can't fetch a package with "apt-get install ", try building it from source: "apt-get source  &amp;&amp; cd &lt;package\_dir&gt; &amp;&amp; debian/rules binary".
-  * As of March 2013, 78% of Debian packages have been ported on the Hurd. Of course, bug testing is welcome.
+As of March 2013, 78% of all [Debian](http://www.debian.org/)
+[packages](http://packages.debian.org/) are available for [[Debian
+GNU/Hurd|hurd/running/debian]].  Of course, testing and bug fixing is welcome,
+as we have obviously not tested all of them.
+
+Generally, packages
+that aren't Linux-specific (see [Packages That Won't Be
+Ported](http://www.debian.org/ports/hurd/hurd-devel-debian))
+are expected to work on GNU/Hurd too.  Notably, [X.Org](http://www.x.org/),
+[GNOME](http://www.gnome.org/), [KDE](http://www.kde.org/),
+[Firefox](http://www.mozilla.org/firefox) work. See
+the [[hurd/porting/guidelines]] document for some common build problems and their
+solutions.
diff --git a/open_issues/visudo.mdwn b/open_issues/visudo.mdwn
new file mode 100644
index 00000000..e9892e33
--- /dev/null
+++ b/open_issues/visudo.mdwn
@@ -0,0 +1,22 @@
+[[!meta copyright="Copyright © 2013 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="visudo: /etc/sudoers is busy, try again later"]]
+
+[[!tag open_issue_hurd]]
+
+visudo does not work:
+
+    /etc/sudoers is busy, try again later
+
+Apparently there is some locking that sudo does which does not
+work. Uninvestigated for now.
+
+One can just edit the /etc/sudoers file and take care of correctness by hand.
diff --git a/source_repositories/incubator.mdwn b/source_repositories/incubator.mdwn
index 5e974cae..6d61a9e7 100644
--- a/source_repositories/incubator.mdwn
+++ b/source_repositories/incubator.mdwn
@@ -24,8 +24,6 @@ its branches, usually as a subdirectory of the current repository.
 The advantage of using it for `incubator` is that only one clone is needed,
 and it can be possible to work simultaneously on many branches (instead of
 only on the current branch of that clone).
-The drawback is that updating a subrepository requires updating its branch
-on the main clone first.
 
 Let's start checking out the `incubator` repository:
 
@@ -46,11 +44,3 @@ simplicity, but can be created anywhere else:
 After this, a new `tarfs` subdirectory appears, which represents the
 `tarfs/master` branch.  You can normally work on this new repository as usual.
 
-As said earlier, updating `tarfs` requires fetching/pulling in `incubator`
-first:
-
-    $ cd incubator/
-    incubator$ git pull/fetch
-    incubator$ cd tarfs/
-    tarfs$ git pull/fetch
-
diff --git a/user/musial.mdwn b/user/musial.mdwn
index a06abe06..2235e492 100644
--- a/user/musial.mdwn
+++ b/user/musial.mdwn
@@ -12,6 +12,6 @@ License|/fdl]]."]]"""]]
 
 email: musial at gnu dot org
 
-http://mu5141.com
+http://musial.musialx.com
 
 Join the FSF! - http://www.fsf.org/register_form?referrer=9143