diff options
Diffstat (limited to 'community/gsoc/project_ideas/mtab.mdwn')
| -rw-r--r-- | community/gsoc/project_ideas/mtab.mdwn | 77 |
1 files changed, 0 insertions, 77 deletions
diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn deleted file mode 100644 index 0c0bb87b..00000000 --- a/community/gsoc/project_ideas/mtab.mdwn +++ /dev/null @@ -1,77 +0,0 @@ -[[!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]]."]]"""]] - -[[!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`. - -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. - -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|hurd/translator/mtabfs]], and the -necessary interface(s) for gathering the data. It requires getting a good -understanding of the translator mechanism and Hurd interfaces in general. - -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. |