diff options
Diffstat (limited to 'user')
| -rw-r--r-- | user/scolobb.mdwn | 68 |
1 files changed, 46 insertions, 22 deletions
diff --git a/user/scolobb.mdwn b/user/scolobb.mdwn index 32a12737..9044e278 100644 --- a/user/scolobb.mdwn +++ b/user/scolobb.mdwn @@ -149,36 +149,60 @@ For documentation, see [[hurd/translator/unionmount]]. underlying node of unionfs** *(17 Jul)* Such functionality makes `unionmount` even more transparent. -* **Try to make `eth-multiplexer` work with statically set instances - of `devnode`** *(3 Aug)* The problem was in the fact that the root - node of `eth-multiplexer` was not treated completely similarly as - other nodes; specifically no pseudo master device port was created - for it. Minor modifications to some conditions solved the problem. +* **Try to make `eth-multiplexer` work with static instances of + `devnode`** *(3 Aug)* A static `devnode` translator is a `devnode` + translator which is told to use the eth-multiplexer's pseudo master + device port via the "-M" option. Technically it looks like + `settrans -a <node> devnode -M <dir> <device-name>`, where `<dir>` + is the node on which eth-multiplexer is running. -### TODO + The problem was in the fact that the root node of `eth-multiplexer` + was not treated completely similarly as other nodes; specifically no + device port was created for it. Minor modifications to some + conditions solved the problem. -(Dates in brackets show the *expected* completion date) +* **Add the `MASTER` node to `eth-multiplexer`** *(5 Aug)* The + `MASTER` node, published by eth-multiplexer, allows creating any + number of virtual devices. This node is mainly accessed by static + instances of `devnode` to setup their corresponding virtual devices. + +* **Add support for priorities** *(6 Aug)* Now the mountee's + filesystem can be configured to "lie" beneath other filesystems. + +* **Use `unionmount` to merge the virtual filesystem of + `eth-multiplexer` with its underlying filesystem** *(7 Aug)* + `eth-multiplexer` can is unionmounted to "lie beneath" it's + underlying filesystem. If, for example, the multiplexer is + unionmounted on `veth/`, the user can both set (static) `devnode` + translator on the nodes shown in `veth/` and belonging to the + underlying filesystem and create normal virtual multiplexer devices + by accessing any node (not present in the underlying filesystem) and + opening a device using the port to the node as a pseudo device port. + +* **Rename the `MASTER` node into `.MASTER`** (7 Aug) This name seems + more natural for a special-purpose node. -* **Wrap the "--mount" patch series** *(2 Aug)* It's top priority to - make do the final corrections to these patches and to apply them to - the `master-unionmount` branch. +* **Set the stat information for `eth-multiplexer` nodes in + `netfs_validate_stat`** (9 Aug) In the initial version the stat + information was set up properly only at device creation. Before + that the stat information was copied from the underlying node, which + baffled `unionmount`. Now the stat information is setup in + `netfs_validate_stat`. -* **Employ `unionmount` in `eth-multiplexer`.** *(4 Aug)* `unionmount` - will have to merge the dynamic filesystem of `eth-multiplexer` with - the directory tree it will be sitting on. The latter directory tree - will contain static nodes with `devnode` translators. +* **Supply the mountee with the real root.** *(14 Aug)* Since the + mountee is *not attached* to its underlying node, it is okay to + supply it with the real root node of `unionfs`. The mountee's + filesystem will not obscure the `unionfs`'s one because the mountee + is *not attached* to the root node. -* **Wrap up the project for upstream inclusion.** *(7 Aug)* +### TODO + +(Dates in brackets show the *expected* completion date) + +* **Wrap up the project for upstream inclusion.** *(28 Aug)* `unionmount` is intended to be included upstream, therefore it should be mostly complete and polished by the end of GSoC. -* **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. - --- # Google Summer of Code: 2008 Project: Namespace-based translator selection |