bug-hurd
[Top][All Lists]
Advanced

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

Re: [PATCH 0/5] Change unionfs argument handling policy


From: olafBuddenhagen
Subject: Re: [PATCH 0/5] Change unionfs argument handling policy
Date: Sun, 31 May 2009 20:08:10 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

On Wed, May 27, 2009 at 08:48:56PM +0200, Thomas Schwinge wrote:

> In the end, how much code will be shared between unionfs and
> unionmount? Would it perhaps make sense -- in the long term, need not
> be right now -- to transfer the guts of unionfs into a library that
> can then be shared between unionfs and unionmount?

We have discussed various options for code reuse: unionmount shares
common functionality both with unionfs, and with nsmux. We need to see
how that can be factorized best; but we decided to postpone these
consideration until after a first implementation of unionmount works...

BTW, I don't like shared libraries very much. Whenever possible, code
reuse should happen by invoking external processes, rather than by
linking libraries -- that's the UNIX philosophy.

> For now, as you forked the unionfs code, I suggest development to
> happen in the unionfs Git repository, on a separate branch, named
> perhaps master-unionmount (going with my naming scheme detailed on
> <http://www.gnu.org/software/hurd/rules/source_repositories.html> --
> other suggestions are still welcome! -- this would mean that it is
> branched off of master and has the topic unionmount).

Yeah, that's what we decided to do for now.

BTW, the "master-" bit seems pointless to me. You can always check the
history, if you need to know where the branch originates from.

> If working on this branch should become unwieldy for a reason or
> another, we can easily move that branch into a separate unionmount Git
> repository.

Actually, I believe that both unionfs and unionmount should go into
seperate directories in the main Hurd tree.

> So, unionmount will in fact be a melange of what unionfs is at the
> moment, but limited to one additional (implicit) filesystem (in
> unionfs parlance) and all that in the context of how settrans is used
> at the moment?

Yeah, that sounds about right I'd say... :-)

> Wouldn't even a syntax like ``settrans --unionmount ...'' make sense
> perhaps?

We briefly discussed the option of extending settrans, though only in
the context of a library-based rather than translator-based
implementation...

But now that you mention it, I see that indeed it might be an
interesting option to let settrans do all the setup, and have the
translator component only serve as a helper... We definitely need to
think about that at some point. I hope Sergiu is taking notes :-)

> I guess that would be the first thing to come up with some examples --
> and I have to admit that I don't completely grok those on the web pages
> mentioned above whan reading them for the first time -- that this
> functionality is useful for.

Well, an obvious example is mounting a ramdisk over a read-only store: With
unionfs, you first need to explicitely mount the ramdisk in some temporary
location, and only then can set up the unionfs using it. With a union mount,
you can mount the ramdisk right at the target location.

-antrik-




reply via email to

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