Merge commit 'ce4899ded119f3607515cc54252c4bad7224f804'

Conflicts:
	community/gsoc/project_ideas/mtab.mdwn
	contributing.mdwn
	hurd/translator/eth-filter.mdwn
	hurd/translator/socketio.mdwn
	open_issues/exec.mdwn
	open_issues/gnumach_vm_object_resident_page_count.mdwn
	public_hurd_boxen.mdwn

2 files changed, 3 insertions, 78 deletions

diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn
deleted file mode 100644
index 0c0bb87b..00000000
--- a/community/gsoc/project_ideas/mtab.mdwn
+++ /dev/null
@@ -1,77 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 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="mtab"]]
-
-[[!tag open_issue_hurd]]
-
-In traditional monolithic system, the kernel keeps track of all mounts; the
-information is available through `/proc/mounts` (on Linux at least), and in a
-very similar form in `/etc/mtab`.
-
-The Hurd on the other hand has a totally
-[[decentralized_file_system|hurd/virtual_file_system]].  There is no single
-entity involved in all mounts.  Rather, only the parent file system to which a
-mountpoint ([[hurd/translator]]) is attached is involved.  As a result, there
-is no central place keeping track of mounts.
-
-As a consequence, there is currently no easy way to obtain a listing of all
-mounted file systems. This also means that commands like `df` can only work on
-explicitly specified mountpoints, instead of displaying the usual listing.
-
-One possible solution to this would be for the translator startup mechanism to
-update the `mtab` on any `mount`/`unmount`, like in traditional systems.
-However, there are some problems with this approach.  Most notably: what to do
-with passive translators, i.e., translators that are not presently running, but
-set up to be started automatically whenever the node is accessed?  Probably
-these should be counted among the mounted filesystems; but how to handle the
-`mtab` updates for a translator that is not started yet?  Generally, being
-centralized and event-based, this is a pretty inelegant, non-hurdish solution.
-
-A more promising approach is to have `mtab` exported by a special translator,
-which gathers the necessary information on demand.  This could work by
-traversing the tree of translators, asking each one for mount points attached
-to it.  (Theoretically, it could also be done by just traversing *all* nodes,
-checking each one for attached translators.  That would be very inefficient,
-though.  Thus a special interface is probably required, that allows asking a
-translator to list mount points only.)
-
-There are also some other issues to keep in mind.  Traversing arbitrary
-translators set by other users can be quite dangerous -- and it's probably not
-very interesting anyways what private filesystems some other user has mounted.
-But what about the global `/etc/mtab`?  Should it list only root-owned
-filesystems?  Or should it create different listings depending on what user
-contacts it?...
-
-That leads to a more generic question: which translators should be actually
-listed?  There are different kinds of translators: ranging from traditional
-filesystems ([[disks|hurd/libdiskfs]] and other actual
-[[stores|hurd/translator/storeio]]), but also purely virtual filesystems like
-[[hurd/translator/ftpfs]] or [[hurd/translator/unionfs]], and even things that
-have very little to do with a traditional filesystem, like a
-[[gzip_translator|hurd/translator/storeio]],
-[[mbox_translator|hurd/translator/mboxfs]],
-[[xml_translator|hurd/translator/xmlfs]], or various device file translators...
-Listing all of these in `/etc/mtab` would be pretty pointless, so some kind of
-classification mechanism is necessary.  By default it probably should list only
-translators that claim to be real filesystems, though alternative views with
-other filtering rules might be desirable.
-
-After taking decisions on the outstanding design questions, the student will
-implement both the actual [[mtab_translator|hurd/translator/mtabfs]], and the
-necessary interface(s) for gathering the data.  It requires getting a good
-understanding of the translator mechanism and Hurd interfaces in general.
-
-Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar)
-
-Exercise: Make some improvement to any of the existing Hurd translators.
-Especially those in [hurdextras](http://www.nongnu.org/hurdextras/) are often
-quite rudimentary, and it shouldn't be hard to find something to improve.
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
index e9e94857..6663eec2 100644
--- a/community/gsoc/project_ideas/valgrind.mdwn
+++ b/community/gsoc/project_ideas/valgrind.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011 Free Software Foundation,
+[[!meta copyright="Copyright © 2009, 2010, 2011, 2013 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -60,6 +60,8 @@ 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.
+Reading the source code of the rpctrace tool would probably be useful to
+understand how the RPC message can be parsed.
 
 The goal of this task is at minimum to make Valgrind grok Mach traps,
 and to implement the generic RPC handler.