Re: [PATCH 5/5] Changed argp parsing policy

[olafBuddenhagen]

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-