Merge commit 'c6ecdd55fc994003a3cabf9fd3adf512908a7d28'

Conflicts:
	hurd/translator/procfs/jkoenig/discussion.mdwn

7 files changed, 89 insertions, 16 deletions

diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index da141dc2..52cd09f7 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -100,6 +100,7 @@ The [[concept|concepts]] of translators creates its own problems, too:
 * [[fatfs]]
 * [[ufs]]
 * [[magic]]
+* [[mtab]]
 * [[unionfs]]
 * [[nfs]]
 * [[symlink]]
diff --git a/hurd/translator/mtab.mdwn b/hurd/translator/mtab.mdwn
new file mode 100644
index 00000000..8eca15b9
--- /dev/null
+++ b/hurd/translator/mtab.mdwn
@@ -0,0 +1,23 @@
+[[!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]]."]]"""]]
+
+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.
+
+The `mtab` translator has been implemented; see the [[discussion]] subpage for
+design considerations.
diff --git a/community/gsoc/project_ideas/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
index 716fb492..0734e1e6 100644
--- a/community/gsoc/project_ideas/mtab/discussion.mdwn
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
+[[!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
@@ -8,7 +9,57 @@ 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]]
+[[!tag open_issue_documentation]] The following text needs to be updated.
+
+# Original Project Description
+
+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, and the
+necessary interface(s) for gathering the data.  It requires getting a good
+understanding of the translator mechanism and Hurd interfaces in general.
+
 
 # IRC, freenode, #hurd, 2013-04-17
 
@@ -40,8 +91,7 @@ License|/fdl]]."]]"""]]
     <kuldeepdhaka> braunr, whats ur opinion?
     <pinotree> you don't need a mtab to "unmount" things on hurd
     <braunr> kuldeepdhaka: hum, have you read the project idea ?
-    <braunr>
-      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/
+
     <braunr> 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
@@ -125,9 +175,7 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
 
     <teythoon> so tell me about the more hurdish way of dealing with that issue
     <teythoon> creating a specialized translator for this?
-    <braunr> 11:45 < pinotree> there's also
-      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/
-      about that topic
+
     <braunr> you need to avoid thinking with centralization in mind
     <braunr> the hurd is a distributed system in practice
     <braunr> i think proc is the only centralized component in there
@@ -2070,3 +2118,5 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
     <teythoon> so it might be a problem with either libnetfs (which afaics has
       never supported passive translator records before) or procfs, but tbh I
       haven't investigated this yet
+
+[[open_issues/libnetfs_passive_translators]].
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index 44b8cc77..fc071337 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -150,8 +150,7 @@ License|/fdl]]."]]"""]]
     <youpi> it "just" needs to be commited :)
     <antrik> in either case, it can't hurt to bring this up again :-)
 
-[[community/gsoc/project_ideas/mtab/discussion]], *IRC, freenode, #hurd,
-2013-09-07*.
+[[mtab/discussion]], *IRC, freenode, #hurd, 2013-09-07*.
 
 
 # root group
@@ -305,7 +304,7 @@ License|/fdl]]."]]"""]]
       i don't remember)
     < pinotree> not a strict need
 
-See also [[community/gsoc/project_ideas/mtab]].
+A [[mtab]] translator now exists.
 
 
 ## IRC, freenode, #hurd, 2013-09-20
diff --git a/open_issues/libnetfs_passive_translators.mdwn b/open_issues/libnetfs_passive_translators.mdwn
index db4c9005..c89d27f7 100644
--- a/open_issues/libnetfs_passive_translators.mdwn
+++ b/open_issues/libnetfs_passive_translators.mdwn
@@ -52,4 +52,4 @@ License|/fdl]]."]]"""]]
     <teythoon> 0 tmp/mounts
     <teythoon> and no mtab translator around either
 
-[[community/gsoc/project_ideas/mtab/discussion]].
+[[hurd/translator/mtab/discussion]].
diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn
index 91838f60..ecfa06ae 100644
--- a/open_issues/mig_portable_rpc_declarations.mdwn
+++ b/open_issues/mig_portable_rpc_declarations.mdwn
@@ -69,8 +69,7 @@ License|/fdl]]."]]"""]]
     <teythoon> my use case is getting info about fs translators from init to
       procfs
 
-[[community/gsoc/project_ideas/mtab]],
-[[community/gsoc/project_ideas/mtab/discussion]].
+[[hurd/translator/mtab]], [[hurd/translator/mtab/discussion]].
 
     <teythoon> should I go for an iterator like interface instead?
     <braunr> depends
@@ -136,8 +135,7 @@ License|/fdl]]."]]"""]]
       top of mach
     <braunr> there is a lot of knowledge about mach ports in mig
 
-[[community/gsoc/project_ideas/mtab]],
-[[community/gsoc/project_ideas/mtab/discussion]].
+[[hurd/translator/mtab]], [[hurd/translator/mtab/discussion]].
 
     <teythoon> but again I face the challenge of serializing a arbitrary sized
       list of arbitrary sized strings
diff --git a/user/jkoenig/d-i.mdwn b/user/jkoenig/d-i.mdwn
index 0b9f9f7d..9721b928 100644
--- a/user/jkoenig/d-i.mdwn
+++ b/user/jkoenig/d-i.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 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
@@ -92,6 +92,8 @@ I will be keeping track of my progress on this page.
 
 * (./) **base-installer**: (2010-06-26)
     * Work around non-existant /proc/mounts.
+        * A [[hurd/translator/mtab]] translator now exists; can use that for
+          [[`proc/mounts`|hurd/translator/procfs/jkoenig/discussion]]?
     * Firmlink /servers into /target after debootstrap
       to make the network available.