From 41384151ead1facfedc1cef179d83b819aef9792 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 29 May 2009 17:08:33 +0200 Subject: Merge scolobb's new page into his old user page. --- user/scolobb.mdwn | 47 +++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 43 insertions(+), 4 deletions(-) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index 09016edb..b481f235 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009 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 @@ -8,13 +8,52 @@ 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]]."]]"""]] -# scolobb -Sergiu Ivanov, interested non-student +Sergiu Ivanov Mail: -Project: Namespace-based translator selection + +# Google Summer of Code: 2009 Project + +**Unionmount**: The goal of this project is to make it possible to +mount a translator on a node in such a way that the contents of the +node be merged with the (virtual) filesystem published by the +translator. + +For documentation, see [[hurd/translator/unionmount]]. + +--- + +## Roadmap + +### DONE + +* Make unionfs build. + +* Change the command line parsing in unionfs to comply with the + requirements of unionmount. + +* Start the mountee. + +### TODO + +* Include the filesystem published by the mountee in the list of + merged filesystems. + +* Use a different (better?) implementation idea. + +* Write documentation. + +* Push the unionmount branch (*master-scolobb-unionmount*) to the + unionfs repository. + +* Derive an independent repository based on the + *master-scolobb-unionmount* branch. + +--- + +# Google Summer of Code: 2008 Project: Namespace-based translator selection --- -- cgit v1.3.1 From 8800780df513e8063cf68416686299b1c27d46af Mon Sep 17 00:00:00 2001 From: scolobb Date: Tue, 2 Jun 2009 12:17:10 +0000 Subject: --- user/scolobb.mdwn | 82 +++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 59 insertions(+), 23 deletions(-) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index b481f235..cddb1c73 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -16,10 +16,10 @@ Mail: # Google Summer of Code: 2009 Project -**Unionmount**: The goal of this project is to make it possible to -mount a translator on a node in such a way that the contents of the -node be merged with the (virtual) filesystem published by the -translator. +**Unionmount**: The goal of this project is to make it possible to set +translators in unionmount mode, which means that the filesystem +published by the mounted translator will get merged with the directory +tree of the node the translator is mounted onto. For documentation, see [[hurd/translator/unionmount]]. @@ -29,27 +29,64 @@ For documentation, see [[hurd/translator/unionmount]]. ### DONE -* Make unionfs build. - -* Change the command line parsing in unionfs to comply with the - requirements of unionmount. - -* Start the mountee. +* **Make `unionfs` build.** For reasons unknown to me, `unionfs` + Makefile was configured to search for include files from under + `$(prefix)/include`, while `$(prefix)` was never defined. Setting + `$(prefix)` to `/usr` solved the problem. + +* **Change the command line parsing in `unionfs` to comply with the + requirements of `unionmount`.** Although the core functionality of + `unionmount` heavily relies on `unionfs`, the command line interface + of these two programs is completely different: `unionfs` operates on + directories, the list of which is explicitly specified, while + `unionmount` *always* merges the underlying filesystem and the + filesystem published by the mountee. Therefore, options like + `--add`, `--remove`, `--underlying` (specific to `unionfs`) make + little sense in `unionmount` context. These options have been + removed. Also, `unionmount` must be able to pass some switches to + the mountee, which means that it should stop parsing the command + line arguments immediately after having encountered the path to the + mountee (very similar to how `settrans` works). This functionality + has also been implemented. + +* **Make `unionmount` capable of starting the mountee.** The idea + behind implementation of this goal is that `unionmount` should + provide a proxy node on which to set the mountee. The main issue + about this goal was the fact that the mountee *cannot* be started + during the initialization of `unionmount`, because in this phase + `unionmount` is not capable of responding to RPCs, while many + translators try to `io_stat` their underlying node or do other + interesting things on startup. The solution to this problem is, + obviously, *lazy* startup, i.e. the mountee is started at the first + attempt to access (via `dir_lookup` or `dir_readdir`) the merged + filesystem published by `unionmount`. + +* **Include the filesystem published by the mountee in the list of + merged filesystems.** `unionfs` operates on a list of ports to the + underlying filesystems, therefore, to finish the unionmount + functionality, I had to include the port to the mountee in this + list. ### TODO -* Include the filesystem published by the mountee in the list of - merged filesystems. - -* Use a different (better?) implementation idea. - -* Write documentation. - -* Push the unionmount branch (*master-scolobb-unionmount*) to the - unionfs repository. - -* Derive an independent repository based on the - *master-scolobb-unionmount* branch. +* **Use a different (better?) implementation idea.** It has been + pointed out several times that `unionmount` could be implemented not + by forking off `unionfs`, but by keeping the merging functionality + in a stand-alone module (which could then be used by `unionfs` as + well). Different implementation ideas with their own specific + advantages may also arise in the future. + +* **Write documentation.** The basic unionmount functionality being + finished, it has to be documented properly, lest it should lag + behind and remain unfinished eventually. + +* **Decide as to location of unionmount.** Presently, `unionmount` is + a (local) branch in `unionfs` git repository. The first step of + publishing it is planned to be pushing it to the Savannah `unionfs` + repository. Some agree that there should also be a second step + consisting in splitting `unionmount` in a separate git repository, + since the destinations of `unionfs` and `unionmount` are *similar*, + and not identical. --- @@ -170,4 +207,3 @@ The code is at . ####0: Sun Apr 27: > Followed the code of *dmesgd* () kindly offered by **bddebian** and rewrote it from scratch as a tutorial. - -- cgit v1.3.1 From 56bb6a8174127aa6f7621cd49e9af2856f168c15 Mon Sep 17 00:00:00 2001 From: scolobb Date: Tue, 2 Jun 2009 13:06:59 +0000 Subject: --- user/scolobb.mdwn | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index cddb1c73..4817a002 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -69,6 +69,15 @@ For documentation, see [[hurd/translator/unionmount]]. ### TODO +* **Write documentation for `unionmount`.** The basic unionmount + functionality being finished, it has to be documented properly, lest + it should lag behind and remain unfinished eventually. + +* **Write documentation for `unionfs`.** `unionfs` is not exactly + well-documented at the moment, the only help being provided by the + comments in the sources. The goal is to write a more coherent + documentation. + * **Use a different (better?) implementation idea.** It has been pointed out several times that `unionmount` could be implemented not by forking off `unionfs`, but by keeping the merging functionality @@ -76,10 +85,6 @@ For documentation, see [[hurd/translator/unionmount]]. well). Different implementation ideas with their own specific advantages may also arise in the future. -* **Write documentation.** The basic unionmount functionality being - finished, it has to be documented properly, lest it should lag - behind and remain unfinished eventually. - * **Decide as to location of unionmount.** Presently, `unionmount` is a (local) branch in `unionfs` git repository. The first step of publishing it is planned to be pushing it to the Savannah `unionfs` @@ -88,6 +93,9 @@ For documentation, see [[hurd/translator/unionmount]]. since the destinations of `unionfs` and `unionmount` are *similar*, and not identical. +* **Employ `unionmount` in eth-multiplexer.** I still have to scrounge + for details. + --- # Google Summer of Code: 2008 Project: Namespace-based translator selection -- cgit v1.3.1 From 564f3b1b7a1c349f5ce811c15dd71b14543789f3 Mon Sep 17 00:00:00 2001 From: scolobb Date: Tue, 2 Jun 2009 13:12:55 +0000 Subject: --- user/scolobb.mdwn | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index 4817a002..d2194f49 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -78,12 +78,11 @@ For documentation, see [[hurd/translator/unionmount]]. comments in the sources. The goal is to write a more coherent documentation. -* **Use a different (better?) implementation idea.** It has been - pointed out several times that `unionmount` could be implemented not - by forking off `unionfs`, but by keeping the merging functionality - in a stand-alone module (which could then be used by `unionfs` as - well). Different implementation ideas with their own specific - advantages may also arise in the future. +* **Implement merging rules.** Some details are still awaiting + discovery by me. + +* **Employ `unionmount` in eth-multiplexer.** I still have to scrounge + for details. * **Decide as to location of unionmount.** Presently, `unionmount` is a (local) branch in `unionfs` git repository. The first step of @@ -93,8 +92,12 @@ For documentation, see [[hurd/translator/unionmount]]. since the destinations of `unionfs` and `unionmount` are *similar*, and not identical. -* **Employ `unionmount` in eth-multiplexer.** I still have to scrounge - for details. +* **Use a different (better?) implementation idea.** It has been + pointed out several times that `unionmount` could be implemented not + by forking off `unionfs`, but by keeping the merging functionality + in a stand-alone module (which could then be used by `unionfs` as + well). Different implementation ideas with their own specific + advantages may also arise in the future. --- -- cgit v1.3.1 From 3787f8a6d3e270c5b4aacb9217d1c3af9545cbbb Mon Sep 17 00:00:00 2001 From: scolobb Date: Tue, 2 Jun 2009 13:30:05 +0000 Subject: --- user/scolobb.mdwn | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index d2194f49..2b518b06 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -69,14 +69,20 @@ For documentation, see [[hurd/translator/unionmount]]. ### TODO -* **Write documentation for `unionmount`.** The basic unionmount - functionality being finished, it has to be documented properly, lest - it should lag behind and remain unfinished eventually. - -* **Write documentation for `unionfs`.** `unionfs` is not exactly - well-documented at the moment, the only help being provided by the - comments in the sources. The goal is to write a more coherent - documentation. +(Dates in brackets show the approximate deadline) + +* **Learn texinfo.** (Fri, 5 Jun) In order to produce canonical + documentation I will have to learn the texinfo documentation format. + +* **Write documentation for `unionmount`.** (Fri, 5 Jun) The basic + unionmount functionality being finished, it has to be documented + properly, lest it should lag behind and remain unfinished + eventually. + +* **Write documentation for `unionfs`.** (Fri, 5 Jun) `unionfs` + is not exactly well-documented at the moment, the only help being + provided by the comments in the sources. The goal is to write a more + coherent documentation. * **Implement merging rules.** Some details are still awaiting discovery by me. -- cgit v1.3.1 From d55fb0b1546e32389ca2c5b45d1cf669ee2bc32a Mon Sep 17 00:00:00 2001 From: scolobb Date: Tue, 2 Jun 2009 13:43:33 +0000 Subject: --- user/scolobb.mdwn | 54 +++++++++++++++++++++++++++--------------------------- 1 file changed, 27 insertions(+), 27 deletions(-) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index 2b518b06..fd6c6aad 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -71,39 +71,39 @@ For documentation, see [[hurd/translator/unionmount]]. (Dates in brackets show the approximate deadline) -* **Learn texinfo.** (Fri, 5 Jun) In order to produce canonical +* **Learn texinfo.** *(5 Jun)* In order to produce canonical documentation I will have to learn the texinfo documentation format. -* **Write documentation for `unionmount`.** (Fri, 5 Jun) The basic +* **Write documentation for `unionmount`.** *(5 Jun)* The basic unionmount functionality being finished, it has to be documented properly, lest it should lag behind and remain unfinished eventually. -* **Write documentation for `unionfs`.** (Fri, 5 Jun) `unionfs` - is not exactly well-documented at the moment, the only help being - provided by the comments in the sources. The goal is to write a more - coherent documentation. - -* **Implement merging rules.** Some details are still awaiting - discovery by me. - -* **Employ `unionmount` in eth-multiplexer.** I still have to scrounge - for details. - -* **Decide as to location of unionmount.** Presently, `unionmount` is - a (local) branch in `unionfs` git repository. The first step of - publishing it is planned to be pushing it to the Savannah `unionfs` - repository. Some agree that there should also be a second step - consisting in splitting `unionmount` in a separate git repository, - since the destinations of `unionfs` and `unionmount` are *similar*, - and not identical. - -* **Use a different (better?) implementation idea.** It has been - pointed out several times that `unionmount` could be implemented not - by forking off `unionfs`, but by keeping the merging functionality - in a stand-alone module (which could then be used by `unionfs` as - well). Different implementation ideas with their own specific - advantages may also arise in the future. +* **Write documentation for `unionfs`.** *(5 Jun)* `unionfs` is not + exactly well-documented at the moment, the only help being provided + by the comments in the sources. The goal is to write a more coherent + documentation. + +* **Implement merging rules.** *(1 Aug)* Some details are still + awaiting discovery by me. + +* **Employ `unionmount` in eth-multiplexer.** *(10 Aug)* I still have + to scrounge for details. + +* **Decide as to location of unionmount.** *(1 Aug)* Presently, + `unionmount` is a (local) branch in `unionfs` git repository. The + first step of publishing it is planned to be pushing it to the + Savannah `unionfs` repository. Some agree that there should also be + a second step consisting in splitting `unionmount` in a separate git + repository, since the destinations of `unionfs` and `unionmount` are + *similar*, and not identical. + +* **Use a different (better?) implementation idea.** *(17 Aug)* It has + been pointed out several times that `unionmount` could be + implemented not by forking off `unionfs`, but by keeping the merging + functionality in a stand-alone module (which could then be used by + `unionfs` as well). Different implementation ideas with their own + specific advantages may also arise in the future. --- -- cgit v1.3.1 From 5a85e1e17cd181e5e6ea6a8bd3381e589d319486 Mon Sep 17 00:00:00 2001 From: scolobb Date: Tue, 2 Jun 2009 14:26:13 +0000 Subject: --- user/scolobb.mdwn | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index fd6c6aad..0a37bc64 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -84,11 +84,12 @@ For documentation, see [[hurd/translator/unionmount]]. by the comments in the sources. The goal is to write a more coherent documentation. -* **Implement merging rules.** *(1 Aug)* Some details are still +* **Implement merging rules.** *(25 Jul)* Some details are still awaiting discovery by me. -* **Employ `unionmount` in eth-multiplexer.** *(10 Aug)* I still have - to scrounge for details. +* **Wrap up the project for upstream inclusion.** *(1 Aug)* + `unionmount` is intended to be included upstream, therefore it + should be mostly complete and polished by the end of GSoC. * **Decide as to location of unionmount.** *(1 Aug)* Presently, `unionmount` is a (local) branch in `unionfs` git repository. The @@ -98,6 +99,9 @@ For documentation, see [[hurd/translator/unionmount]]. repository, since the destinations of `unionfs` and `unionmount` are *similar*, and not identical. +* **Employ `unionmount` in eth-multiplexer.** *(10 Aug)* I still have + to scrounge for details. + * **Use a different (better?) implementation idea.** *(17 Aug)* It has been pointed out several times that `unionmount` could be implemented not by forking off `unionfs`, but by keeping the merging -- cgit v1.3.1 From 32ce4633c851a65577c58dfeb9a0aaa67c942463 Mon Sep 17 00:00:00 2001 From: scolobb Date: Sun, 7 Jun 2009 09:23:11 +0000 Subject: --- user/scolobb.mdwn | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index 0a37bc64..e7c1adf0 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -67,22 +67,21 @@ For documentation, see [[hurd/translator/unionmount]]. functionality, I had to include the port to the mountee in this list. -### TODO +* **Learn Texinfo.** In order to produce canonical documentation I had + to learn the Texinfo documentation format. -(Dates in brackets show the approximate deadline) +* **Write documentation for `unionmount`.** The basic unionmount + functionality being finished, it has to be documented properly, lest + it should lag behind and remain unfinished eventually. -* **Learn texinfo.** *(5 Jun)* In order to produce canonical - documentation I will have to learn the texinfo documentation format. +* **Write documentation for `unionfs`.** `unionfs` is not exactly + well-documented at the moment, the only help being provided by the + comments in the sources. The goal is to write a more coherent + documentation. -* **Write documentation for `unionmount`.** *(5 Jun)* The basic - unionmount functionality being finished, it has to be documented - properly, lest it should lag behind and remain unfinished - eventually. +### TODO -* **Write documentation for `unionfs`.** *(5 Jun)* `unionfs` is not - exactly well-documented at the moment, the only help being provided - by the comments in the sources. The goal is to write a more coherent - documentation. +(Dates in brackets show the approximate deadline) * **Implement merging rules.** *(25 Jul)* Some details are still awaiting discovery by me. -- cgit v1.3.1 From 66ed0227b1186a36b6a2f9908a6a3cf6b306b6d9 Mon Sep 17 00:00:00 2001 From: scolobb Date: Tue, 9 Jun 2009 15:00:19 +0000 Subject: --- user/scolobb.mdwn | 89 ++++++++++++++++++++++++++++++------------------------- 1 file changed, 49 insertions(+), 40 deletions(-) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index e7c1adf0..f238093b 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -29,32 +29,34 @@ For documentation, see [[hurd/translator/unionmount]]. ### DONE -* **Make `unionfs` build.** For reasons unknown to me, `unionfs` - Makefile was configured to search for include files from under - `$(prefix)/include`, while `$(prefix)` was never defined. Setting - `$(prefix)` to `/usr` solved the problem. +(Dates in brackets show the completion date) + +* **Make `unionfs` build.** *(24 May)* For reasons unknown to me, + `unionfs` Makefile was configured to search for include files from + under `$(prefix)/include`, while `$(prefix)` was never + defined. Setting `$(prefix)` to `/usr` solved the problem. * **Change the command line parsing in `unionfs` to comply with the - requirements of `unionmount`.** Although the core functionality of - `unionmount` heavily relies on `unionfs`, the command line interface - of these two programs is completely different: `unionfs` operates on - directories, the list of which is explicitly specified, while - `unionmount` *always* merges the underlying filesystem and the - filesystem published by the mountee. Therefore, options like - `--add`, `--remove`, `--underlying` (specific to `unionfs`) make - little sense in `unionmount` context. These options have been - removed. Also, `unionmount` must be able to pass some switches to - the mountee, which means that it should stop parsing the command - line arguments immediately after having encountered the path to the - mountee (very similar to how `settrans` works). This functionality - has also been implemented. - -* **Make `unionmount` capable of starting the mountee.** The idea - behind implementation of this goal is that `unionmount` should - provide a proxy node on which to set the mountee. The main issue - about this goal was the fact that the mountee *cannot* be started - during the initialization of `unionmount`, because in this phase - `unionmount` is not capable of responding to RPCs, while many + requirements of `unionmount`.** *(25 May)* Although the core + functionality of `unionmount` heavily relies on `unionfs`, the + command line interface of these two programs is completely + different: `unionfs` operates on directories, the list of which is + explicitly specified, while `unionmount` *always* merges the + underlying filesystem and the filesystem published by the + mountee. Therefore, options like `--add`, `--remove`, `--underlying` + (specific to `unionfs`) make little sense in `unionmount` + context. These options have been removed. Also, `unionmount` must be + able to pass some switches to the mountee, which means that it + should stop parsing the command line arguments immediately after + having encountered the path to the mountee (very similar to how + `settrans` works). This functionality has also been implemented. + +* **Make `unionmount` capable of starting the mountee.** *(28 May)* + The idea behind implementation of this goal is that `unionmount` + should provide a proxy node on which to set the mountee. The main + issue about this goal was the fact that the mountee *cannot* be + started during the initialization of `unionmount`, because in this + phase `unionmount` is not capable of responding to RPCs, while many translators try to `io_stat` their underlying node or do other interesting things on startup. The solution to this problem is, obviously, *lazy* startup, i.e. the mountee is started at the first @@ -62,26 +64,33 @@ For documentation, see [[hurd/translator/unionmount]]. filesystem published by `unionmount`. * **Include the filesystem published by the mountee in the list of - merged filesystems.** `unionfs` operates on a list of ports to the - underlying filesystems, therefore, to finish the unionmount - functionality, I had to include the port to the mountee in this - list. - -* **Learn Texinfo.** In order to produce canonical documentation I had - to learn the Texinfo documentation format. - -* **Write documentation for `unionmount`.** The basic unionmount - functionality being finished, it has to be documented properly, lest - it should lag behind and remain unfinished eventually. - -* **Write documentation for `unionfs`.** `unionfs` is not exactly - well-documented at the moment, the only help being provided by the - comments in the sources. The goal is to write a more coherent + merged filesystems.** *(1 Jun)* `unionfs` operates on a list of + ports to the underlying filesystems, therefore, to finish the + unionmount functionality, I had to include the port to the mountee + in this list. + +* **Learn Texinfo.** *(Jun 4)* In order to produce canonical + documentation I had to learn the Texinfo documentation format. + +* **Write documentation for `unionmount`.** *(Jun 5)* The basic + unionmount functionality being finished, it has to be documented + properly, lest it should lag behind and remain unfinished + eventually. + +* **Write documentation for `unionfs`.** *(Jun 5)* `unionfs` is not + exactly well-documented at the moment, the only help being provided + by the comments in the sources. The goal is to write a more coherent documentation. ### TODO -(Dates in brackets show the approximate deadline) +(Dates in brackets show the *expected* completion date) + +* **Start with a clean unionfs and implement the `--mount` argument** + *(12 Jun)* It was suggested to implement the union mount + functionality first, instead of doing some partial adaptation of + `unionfs` to `unionmount` and leaving the complete adaptation for + the future. * **Implement merging rules.** *(25 Jul)* Some details are still awaiting discovery by me. -- cgit v1.3.1 From b56910f1ded80a753c71e32e21f50cf6776a5d88 Mon Sep 17 00:00:00 2001 From: scolobb Date: Tue, 9 Jun 2009 16:08:34 +0000 Subject: --- user/scolobb.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'user') diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index f238093b..2182f12e 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -86,6 +86,10 @@ For documentation, see [[hurd/translator/unionmount]]. (Dates in brackets show the *expected* completion date) +* **Study eth-multiplexer.** *(12 Jun)* In order to get an idea of + what should the rules for eth-multipexer be, I will have to study + the current state of eth-multiplexer. + * **Start with a clean unionfs and implement the `--mount` argument** *(12 Jun)* It was suggested to implement the union mount functionality first, instead of doing some partial adaptation of -- cgit v1.3.1