bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/3] Add the ``--mount'' command line option


From: Sergiu Ivanov
Subject: Re: [PATCH 1/3] Add the ``--mount'' command line option
Date: Sun, 5 Jul 2009 19:17:33 +0300
User-agent: Mutt/1.5.18 (2008-05-17)

Hello,

On Fri, Jul 03, 2009 at 06:52:37AM +0200, olafBuddenhagen@gmx.net wrote:
> On Thu, Jun 18, 2009 at 11:14:41PM +0300, Sergiu Ivanov wrote:
> > @@ -124,6 +132,13 @@ argp_parse_common_options (int key, char *arg, struct 
> > argp_state *state)
> >        ulfs_match = 0;
> >        break;
> >  
> > +    case OPT_MOUNT:
> > +      /* TODO: Improve the mountee command line parsing mechanism.  */
> > +      err = argz_create_sep (arg, ' ', &mountee_argz, &mountee_argz_len);
> > +      if (err)
> > +   error (EXIT_FAILURE, err, "argz_create_sep");
> > +      break;
> > +
> >      case OPT_UNDERLYING:   /* --underlying  */
> >      case ARGP_KEY_ARG:
> >  
> 
> This surely needs some special handling in netfs_append_args() as
> well?...

Yes, it does, of course.  I didn't implement it right here because I
misunderstood your suggestion to implement the union mount
functionality *before* any command line handling.

However, from my experience with using git, I'd say it shouldn't be
very hard to insert a patch which adapts the behaviour of
netfs_append_args.
 
> BTW, what happens if the user specifies multiple --mount options? From
> the looks of it, it won't blow up completely, but won't really handle it
> in a useful way either?
>
> (A useful way would be either erroring out, or using only the latest
> option and ignoring the others.)

It won't blow up completely, right.  In the current implementation it
*will* actually use the last option.  To make this behaviour
completely safe, I should check whether the mountee_argz has already
been allocated, because presently using multiple --mount options will
result in memory leaks.

Should I just add this check or should error out some message, what do
you think?
 
> Another case I wonder about is mixing of --mount and "ordinary"
> arguments -- is it actually possible to do that?

I did nothing which could limit the functionality of unionfs.
Therefore, I'd suppose that you can mix things however you want.  For
instance, the following works for me:

 $ settrans -a foo unionfs -a /boot/ -u -t /hurd/filterfs

(filterfs is my old filtering translator which I use for testing
purposes; it mirrors /var/tmp/)

By ``works'' I mean that I can go under foo/ and do all normal
operations on a filesystem.

Have I answered your question or have I understood something wrong?

Regards,
scolobb




reply via email to

[Prev in Thread] Current Thread [Next in Thread]