Merge remote-tracking branch 'fp/master'

1 files changed, 90 insertions, 3 deletions

diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn
index a60a8038..694effca 100644
--- a/community/gsoc/project_ideas/mtab.mdwn
+++ b/community/gsoc/project_ideas/mtab.mdwn
@@ -1,12 +1,13 @@
-[[!meta copyright="Copyright © 2008, 2009 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
 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 [[!meta title="mtab"]]
 
@@ -72,3 +73,89 @@ 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.
+
+
+# Related Discussion
+
+## 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