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: Thomas Schwinge
Subject: Re: [PATCH 0/5] Change unionfs argument handling policy
Date: Wed, 27 May 2009 20:48:56 +0200
User-agent: Mutt/1.5.11

Hello!

On Tue, May 26, 2009 at 11:31:45PM +0300, Sergiu Ivanov wrote:
> I am working on unionmount project, which is (at the moment) a branch
> in unionfs git repository
> (http://git.savannah.gnu.org/cgit/hurd/unionfs.git/). The goal of
> unionmount is to mount a translator is such a way that the underlying
> filesystem gets merged with the (virtual) filesystem published by the
> translator.

Here is that project's description, by the way:
<http://www.gnu.org/software/hurd/community/gsoc/project_ideas/unionmount.html>


> I'm posting a series of patches which bring unionfs to an intermediate
> stage on its road towards unionmount

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?

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).  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.


> OTOH, the general command line handling policy should be different for
> unionmount. It should be similar to what settrans does (and this is
> very much different from how unionfs parses its command line). In this
> series of patches there is one which tailors unionfs's command line
> handling policy to the needs of unionmount.

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?  Wouldn't even a syntax like ``settrans --unionmount ...'' make
sense perhaps?

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.  Feel invited to enhance that web page.


Regards,
 Thomas

Attachment: signature.asc
Description: Digital signature


reply via email to

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