diff options
Diffstat (limited to 'community/gsoc/project_ideas')
| -rw-r--r-- | community/gsoc/project_ideas/download_backends.mdwn | 11 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/mtab.mdwn | 161 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/object_lookups.mdwn | 29 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/sound/discussion.mdwn | 47 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/valgrind.mdwn | 2 |
5 files changed, 83 insertions, 167 deletions
diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn index f794e814..c0bdc5b2 100644 --- a/community/gsoc/project_ideas/download_backends.mdwn +++ b/community/gsoc/project_ideas/download_backends.mdwn @@ -1,12 +1,12 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 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="Use Internet Protocol Translators (ftpfs etc.) as Backends for Other Programs"]] @@ -19,8 +19,9 @@ Download protocols like FTP, HTTP, BitTorrent etc. are very good candidates for this kind of modularization: a program could simply use the download functionality by accessing FTP, HTTP etc. translators. -There is already an ftpfs translator in the Hurd tree, as well as an [httpfs -translator on hurdextras](http://www.nongnu.org/hurdextras/#httpfs); however, +There is already an [[hurd/translator/ftpfs]] translator in the Hurd tree, as +well as an [[hurd/translator/httpfs]] on +[hurdextras](http://www.nongnu.org/hurdextras/); however, these are only suitable for very simple use cases: they just provide the actual file contents downloaded from the URL, but no additional status information that are necessary for interactive use. (Progress indication, error codes, HTTP diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn deleted file mode 100644 index 694effca..00000000 --- a/community/gsoc/project_ideas/mtab.mdwn +++ /dev/null @@ -1,161 +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"]] - -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. - - -# 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 diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn index 5075f783..88ffc633 100644 --- a/community/gsoc/project_ideas/object_lookups.mdwn +++ b/community/gsoc/project_ideas/object_lookups.mdwn @@ -40,3 +40,32 @@ accurate measurements in a system that lacks modern profiling tools would also be helpful. Possible mentors: Richard Braun + + +# IRC, freenode, #hurd, 2013-09-18 + +In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. + + <teythoon> braunr: (wrt the gnumach HACK) funny, I was thinking about doind + the same for userspace servers, renaming ports to the address of the + associated object, saving the need for the hash table... + <braunr> teythoon: see + http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/object_lookups/ + <braunr> teythoon: my idea is to allow servers to set a label per port, + obtained at mesage recv time + <braunr> because, yes, looking up an object twice is ridiculous + <braunr> you normally still want port names to be close to 0 because it + allows some data structure optimizations + <teythoon> braunr: yes, I feared that ports should normally be smallish + integers and contigious at best + <teythoon> braunr: interesting that you say there that libihash suffers + from high collision rates + <teythoon> I've a theory to why that is, libihash doesn't do any hashing at + all + <pinotree> there are notes about that in the open_issues section of the + wiki + <teythoon> but I figured that this is probably ok for port names, as they + are small and contigious + <neal> braunr: That's called protected payload. + <neal> braunr: The idea is that the kernel appends data to the message in + flight. diff --git a/community/gsoc/project_ideas/sound/discussion.mdwn b/community/gsoc/project_ideas/sound/discussion.mdwn new file mode 100644 index 00000000..4a95eb62 --- /dev/null +++ b/community/gsoc/project_ideas/sound/discussion.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +[[!taglink open_issue_documentation]]: update [[sound]] page. + + +# IRC, freenode, #hurd, 2013-09-01 + + <rekado> I'm new to the hurd but I'd love to learn enough to work on sound + support. + <rekado> + http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/sound/ + says drivers should be ported to GNU Mach as a first step. + <rekado> Is this information still current or should the existing Linux + driver be wrapped with DDE instead? + <auronandace> if i recall correctly dde is currently only being used for + network drivers. i'm not sure how much work would be involved for sound + or usb + + +## IRC, freenode, #hurd, 2013-09-02 + + <rekado> The sound support proposal + (http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/sound/) + recommends porting some other kernel's sound driver to GNU Mach. Is this + still current or should DDE be used instead? + <pinotree> rekado: dde or anything userspace-based is generally preferred + <braunr> rekado: both are about porting some other kernel's sound driver + <braunr> dde is preferred yes + <rekado> This email says that sound drivers are already partly working with + DDE: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html + <rekado> So, should I just try to get some ALSA kernel parts to compile + with DDE? + <pinotree> well, what is missing is also the dde←→hurd glue + <braunr> rekado: there is also a problem with pci arbitration + <rekado> pinotree: I assumed DDEKit works with the hurd and we could use + any DDE/<other kernel> glue code with it + * rekado looks up pci arbitration + <pinotree> only for networking atm + <rekado> ah, I see. diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn index 76675796..6663eec2 100644 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ b/community/gsoc/project_ideas/valgrind.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009, 2010, 2011 Free Software Foundation, +[[!meta copyright="Copyright © 2009, 2010, 2011, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable |