Hello,
On Mon, Jun 29, 2009 at 01:53:24AM +0200, olafbuddenha...@gmx.net wrote:
> On Mon, Jun 15, 2009 at 09:01:55PM +0300, Sergiu Ivanov wrote:
> > On Sat, Jun 13, 2009 at 03:53:27PM +0200, Carl Fredrik Hammar wrote:
> > > On Thu, Jun 11, 2009 at 09:10:24PM +0300, Sergiu Ivanov wrote:
>
> > > > diff --git a/unionmount.c b/unionmount.c
> > > > new file mode 100644
> > > > index 0000000..e4aa043
> > > > --- /dev/null
> > > > +++ b/unionmount.c
> > >
> > > Given that this is to implement the --mount option, I think mount.c
> > > would be a better name. The context of unionfs establishes that this
> > > means unioning.
> > >
> > > > @@ -0,0 +1,28 @@
> > > > +/* Hurd unionmount
> > > > + The core of unionmount functionality.
> > >
> > > Again the purpose of the file isn't really to implement unionmount,
> > > but to implement the --mount option.
> >
> > The idea is that the ``--mount'' option is just an intermediate step
> > towards a ``stand-alone'' unionmount implementation. That's why I call
> > this file in a more general way than just ``mount''.
>
> *If* we ultimately go with a standalone unionmount -- which isn't even
> certain at this point -- naming it "unionmount.[ch]" would be even more
> wrong than now. The files do not implement unionmount; they only
> implement one specific part of it.
>
> > I remember antrik objecting to this name, too, but I'd like to point
> > out that the information about unionfs itself is declared in
> > unionfs.h. This was the reason why I called the two filed
> > unionmount.{c,h}.
>
> unionfs.h contains definitions relevant for *all* of unionfs, not just
> some specific aspect.
OK, I'll fix the filename and will send in the updated patch shortly.
Regards,
scolobb
