Hi, On Fri, May 29, 2009 at 12:09:04AM +0300, Sergiu Ivanov wrote:
> OBJS = main.o node.o lnode.o ulfs.o ncache.o netfs.o \ > - lib.o options.o pattern.o stow.o update.o > + lib.o options.o pattern.o stow.o update.o unionmount.o "unionmount" is not a good name for a file, when the whole thing is unionmount... (Unless it would be the main file, which it isn't.) As for the patch in general: it changes the handling of arguments when initially parsing, but AIUI it will totally break both reading and setting arguments later on with fsysopts?... Actually, it's probably not even a problem that fsysopts won't work: as we decided that unionmount should be transparent, passing on all requests to the mountee, there is probably no way to actually do fsysopts on unionmount itself... And I don't think it would be very useful to do that anyways. However, if we don't support fsysopts with the new command line handling, all the code related to it should be dropped, in another commit going *before* this one. In fact, I think that both changes, as well as all others regarding command line handling, should probably only happen *after* adding the actual unionmount backend functionality -- the backend can exist without the new interface actually making use of it, while the new interface without the backend won't work at all. The idea behind this is that at any point in a patch series, the program should remain functional. Admittedly, this is probably not very important for the initial unionfs -> unionmount conversion -- but it is a good policy in general, so better stick to it... Note that this doesn't mean you have to actually *develop* the parts in that order -- one of the great things about Git is that it makes reordering changes in various ways pretty easy :-) (Probably even easier with a patch queue manager like StGit, Guilt, or TopGit -- but I haven't looked at these myself so far...) -antrik-
