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-
