diff options
author | Thomas Schwinge <thomas@codesourcery.com> | 2013-07-21 15:35:02 -0400 |
---|---|---|
committer | Thomas Schwinge <thomas@codesourcery.com> | 2013-07-21 15:35:02 -0400 |
commit | 9933cec0a18ae2a3d752f269d1bb12c19f51199d (patch) | |
tree | cc30f2d56b87d3896e460a58b76e964231c0d578 /community/gsoc/project_ideas/mtab.mdwn | |
parent | 65efe654a9cb0b682efa9bf21065469a2e9147f4 (diff) |
IRC.
Diffstat (limited to 'community/gsoc/project_ideas/mtab.mdwn')
-rw-r--r-- | community/gsoc/project_ideas/mtab.mdwn | 98 |
1 files changed, 2 insertions, 96 deletions
diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn index d6f04385..0c0bb87b 100644 --- a/community/gsoc/project_ideas/mtab.mdwn +++ b/community/gsoc/project_ideas/mtab.mdwn @@ -11,6 +11,8 @@ 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`. @@ -73,99 +75,3 @@ 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 - - -## IRC, freenode, #hurd, 2013-06-04 - - <safinaskar> how to see list of all connected translators? - <braunr> you can't directly - <braunr> you can use ps to list processes and guess which are translators - <braunr> (e.g. everything starting with /hurd/) - <braunr> a recursive call to obtain such a list would be useful - <braunr> similar to what's needed to implement /proc/mounts |