Hello, On Sat, Jul 18, 2009 at 07:21:59AM +0200, olafbuddenha...@gmx.net wrote: > (Most of this is only for the record, as we already discussed it on > IRC.)
I will only give some short comments to those points about which I have to say something. > On Fri, Jul 10, 2009 at 08:52:44PM +0300, Sergiu Ivanov wrote: > > * fsys_set_options: in transparent mode this RPC should be completely > > forwarded to the mountee; in non-transparent mode this RPC should be > > handled in unionfs first and the (possibly) new value for the > > ``--mount'' option should be delegated to the mountee; > > I'm not actually sure whether it's useful to handle it like that in the > non-transparent case... > > And I would consider it an additional feature anyways, not really > crucial. I didn't implement this feature. Since such functionality should be an additional feature, I could try to implement it later, because it really isn't crucial to the union mount functionality. > > * fsys_getpriv: * fsys_init: fsys.defs says that these RPCs should > > only be implemented by bootstrap filesystems; since unionfs will > > hardly ever be a bootstrap filesystem, these RPCs will not be > > implemented; > > I'm actually not so sure about that... It *might* be useful to > union-mount the bootstrap filesystem -- I'm just not sure whether it's > even possible in theory :-) I think I must ask the question which has been around my mind for some time: what is a ``bootstrap filesystem''? Is it a filesystem used at Hurd startup (like ext2fs)? If so, unionmount could be used with a bootstrap filesystem in the case of LiveCDs, for instance. > > * fsys_forward: in the previous discussion there is a short > > explanation why this RPC should be left implemented in the default > > version (returning EOPNOTSUPP); > > Well, if it can be easily forwarded, we should -- it *might* be > useful... Unfourtunately, as it has already been discussed on the IRC, I failed to overload netfs_S_fsys_* stubs by simple redifinition of the corresponding functions. This made me stick with netfs_* stubs (not netfs_S_*) and libnetfs does not define a netfs_* stub for fsys_forward. Due to this situation, forwarding fsys_forward looks like a not-really-trivial task, so I'd rather leave it for better times. Regards, scolobb
