<olafbuddenha...@gmx.net> writes: > On Wed, Apr 08, 2009 at 08:17:30PM +0300, Sergiu Ivanov wrote: > >> You see, I suppose that some time later we will be adding some >> specific merging rules, which would be very difficult (if not >> impossible) with the approach you are suggesting (about reusing >> unionfs as a whole). > > On the contrary -- having the merging functionality in a separate > component, would make it easier to replace it...
Completely agreed, but if this separate component is unionfs, we will anyway have to fork off its code base. > As I already pointed out in different contexts (IIRC both in network > virtualization and nsmux discussions), modularity always increases > flexibility, at the cost of lower efficiency and higher overall > complexity. (OTOH the complexity is partially isolated, which can reduce > *local* complexity -- also one of the major advantages of microkernels > and modular designs in general...) Yes, I agree, and that is why I'm working on a project within a microkernel OS :-) > Still I agree with you that for the first implementation, it's probably > better to fork the code and create a monolithic implementation, to keep > things simple... This is good :-) I also stand for simplicity in this problem, although I like modularity, too (as I've pointed out above). >> Moreover, some translators (like unionfs and hence unionmount) would >> like to keep a list of nodes they own and drop nodes when they don't >> need them. This policy would require more effort if a shadow-node >> server is involved. > > Why? I am mainly concerned with the fact that dropping the node will require accessing the shadow-node server (if I understand things correctly), and invoking an RPC is always more effort than just cleaning up a local piece of memory. Regards, scolobb
