summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--hurd/translator.mdwn1
-rw-r--r--hurd/translator/mtab.mdwn23
-rw-r--r--hurd/translator/mtab/discussion.mdwn145
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn4
-rw-r--r--user/jkoenig/d-i.mdwn4
5 files changed, 175 insertions, 2 deletions
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index d4eaf950..f1c07bde 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -97,6 +97,7 @@ The [[concept|concepts]] of translators creates its own problems, too:
* [[ext2fs]]
* [[fatfs]]
* [[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/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
new file mode 100644
index 00000000..ca6a86fd
--- /dev/null
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -0,0 +1,145 @@
+[[!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]]."]]"""]]
+
+[[!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
+
+ <kuldeepdhaka> thinking how to get the listing. traversing would be
+ ineffecient, trying to come up with something better
+ <braunr> what listing ?
+ <braunr> and traversing what ?
+ <kuldeepdhaka> mtab
+ <braunr> well i assumed so
+ <braunr> be more precise please
+ <kuldeepdhaka> when the translator is done initalized <translation
+ info> are written to /etc/mtab <translation info> will be provided
+ by the translator, and when some one want to read the info just read it
+ this way if their is some credentials like ftp sites pass username can be
+ masked by the translator
+ <kuldeepdhaka> if some trans dont want to list them, no need to write to
+ file | while unmounting (sorry i couldnt find the right word) , it
+ will pass the mount node address | <translation info> will have special
+ structure to remove/add mounts example "a /mount-to /mount-from" = add
+ , "r /mount-to" = remove here "/mount-to" will be unique for every
+ mount
+ <kuldeepdhaka> this have a draw back , we would have to trust trans for the
+ listed data | also "/mount-to" + "/mount-from" could be used a
+ combination for making sure that other trans unable remove others trans
+ mount data
+ <kuldeepdhaka> sorry but "also "/mount-to" + "/mount-from" could be used a
+ combination for making sure that other trans unable remove others trans
+ mount data" this is a bad idea if we had to print the whole thing
+ <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
+ points attached to it.
+ <kuldeepdhaka> pinotree, not to unmount, i mean is to remove the
+ <translation data>
+ <braunr> for a first implementation, i'd suggest a recursive traversal of
+ root-owned translators
+ <kuldeepdhaka> braunr, hum, but it did stated it as inefficient
+ <braunr> where ?
+ <kuldeepdhaka> para 5 , line 3
+ <kuldeepdhaka> and line 6
+ <braunr> no
+ <braunr> traversing "all" nodes would be inefficient
+ <braunr> translators which host the nodes of other translators could
+ maintain a simple list of active translators
+ <braunr> ext2fs, e.g. (if that's not already the case) could keep the list
+ of the translators it started
+ <braunr> we can already see that list with pstree for example
+ <braunr> but this new list would only retain those relevant for mtab
+ <braunr> i.e. root-owned ones
+ <pinotree> i would not limit to those though
+ <braunr> and then filter on their type (e.g. file system ones)
+ <braunr> pinotree: why ?
+ <pinotree> this way you could have proper per-user /proc/$pid/mounts info
+ <braunr> we could also very easily have a denial of service
+ <kuldeepdhaka> but how will the mount point and source point will be
+ listed?
+ <braunr> they're returned by the translator
+ <kuldeepdhaka> k
+ <braunr> you ask /, it returns its store and its options, and asks its
+ children recursively
+ <braunr> a /home translator would return its store and its options
+ <braunr> etc..
+ <braunr> each translator would build the complete path before returning it
+ <braunr> sort of, it's very basic
+ <braunr> but that would be a very hurdish way to do it
+ <kuldeepdhaka> shall /etc/mtab should be made seek-able and what should be
+ the filesize? content are generated on demand so, it could arise problem
+ (fsize:0 , seek-able:no), ur opinions?
+ <braunr> kuldeepdhaka: it should have all the properties of a regular file
+ <braunr> the filesize would be determined after it's generated
+ <braunr> being empty doesn't imply it's not seekable
+ <kuldeepdhaka> content is generated on demand so, could cause problem while
+ seeking and filesize, shall i still program as regular file?
+ <kuldeepdhaka> in two different read, it could generate different content,
+ though same seek pos is used...
+ <braunr> what ?
+ <braunr> the content is generated on open
+ <kuldeepdhaka> ooh, ok
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index d26f05f9..b5517b90 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -206,6 +206,8 @@ IRC, freenode, #hurd, 2011-07-25
i don't remember)
< pinotree> not a strict need
+A [[mtab]] translator now exists.
+
# `/proc/[PID]/auxv`, `/proc/[PID]/exe`, `/proc/[PID]/mem`
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.