From 6b366a25f9fd496777ff42932685924eb83696fc Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 24 Apr 2013 11:46:58 +0200 Subject: IRC. --- community/gsoc/project_ideas/mtab.mdwn | 93 ++++++++++++++++++++++++++++++++-- 1 file changed, 90 insertions(+), 3 deletions(-) (limited to 'community') 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 + + thinking how to get the listing. traversing would be + ineffecient, trying to come up with something better + what listing ? + and traversing what ? + mtab + well i assumed so + be more precise please + when the translator is done initalized are written to /etc/mtab 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 + 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 | 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 + 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 + 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 + braunr, whats ur opinion? + you don't need a mtab to "unmount" things on hurd + kuldeepdhaka: hum, have you read the project idea ? + + http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/mtab/ + 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. + pinotree, not to unmount, i mean is to remove the + + for a first implementation, i'd suggest a recursive traversal of + root-owned translators + braunr, hum, but it did stated it as inefficient + where ? + para 5 , line 3 + and line 6 + no + traversing "all" nodes would be inefficient + translators which host the nodes of other translators could + maintain a simple list of active translators + ext2fs, e.g. (if that's not already the case) could keep the list + of the translators it started + we can already see that list with pstree for example + but this new list would only retain those relevant for mtab + i.e. root-owned ones + i would not limit to those though + and then filter on their type (e.g. file system ones) + pinotree: why ? + this way you could have proper per-user /proc/$pid/mounts info + we could also very easily have a denial of service + but how will the mount point and source point will be + listed? + they're returned by the translator + k + you ask /, it returns its store and its options, and asks its + children recursively + a /home translator would return its store and its options + etc.. + each translator would build the complete path before returning it + sort of, it's very basic + but that would be a very hurdish way to do it + 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? + kuldeepdhaka: it should have all the properties of a regular file + the filesize would be determined after it's generated + being empty doesn't imply it's not seekable + content is generated on demand so, could cause problem while + seeking and filesize, shall i still program as regular file? + in two different read, it could generate different content, + though same seek pos is used... + what ? + the content is generated on open + ooh, ok -- cgit v1.2.3