From: "J. Bruce Fields" <bfields@fieldses.org>
To: Steve Dickson <SteveD@redhat.com>
Cc: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>,
linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: nfs-utils and libnfsidmap
Date: Mon, 28 Nov 2011 12:06:44 -0500 [thread overview]
Message-ID: <20111128170644.GA3105@fieldses.org> (raw)
In-Reply-To: <4ED39F2D.7050508@RedHat.com>
On Mon, Nov 28, 2011 at 09:48:13AM -0500, Steve Dickson wrote:
> On 11/23/2011 03:13 PM, J. Bruce Fields wrote:
> > On Wed, Nov 23, 2011 at 08:54:06PM +0100, Tigran Mkrtchyan wrote:
> >> Hi All,
> >>
> >> today was tracing a bug in nfs-utils/libnfsidmap and after a log
> >> debugging located it and
> >> finally realized that it's already fixed by Steve Dickson (
> >> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=d22ef3f525d71b565fcc688557273a6cabeeb71a
> >> ). Nevertheless during
> >> this procedure it turned out that there is quite some code duplicated
> >> between nfs-utils and
> >> libnfsidmap.
> >>
> >> Questions:
> >> a) why nfs-utils duplicates some part of libnfsidmap and still depends o it
> >> b) is there readon for code duplication? Licensing or so
> >> c) what ww need to do to get rid of duplication
> >>
> >> I expect the answer of 'c' will contain something like time and man power.
> >> I am volunteering to to pend some time on it.
> >
> > I doubt there's any real reason for duplication.
> Just curious as to what code we are talking about...
Yes, maybe Tigran can demonstrate with a patch.
> > Probably libnfsidmap should be part of nfs-utils, actually.
> I guess we could roll the libnfsidmap git tree into the nfs-utils
> tree... if that make senses... It probably would simply things..
OK.
> > And maybe we don't need it at all--the original reason to split out
> > libnfsidmap was to share the code with libacl, so the posix getfacl
> > command could do v4->posix acl mapping, but those patches never made it
> > upstream.
> So you don't think this will every happen?
I don't know. If it's easy to keep it as a separate library, then maybe
we should just in case. But for now it seems unlikely.
--b.
next prev parent reply other threads:[~2011-11-28 17:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-23 19:54 nfs-utils and libnfsidmap Tigran Mkrtchyan
2011-11-23 20:13 ` J. Bruce Fields
2011-11-28 14:48 ` Steve Dickson
2011-11-28 17:06 ` J. Bruce Fields [this message]
2011-12-02 14:41 ` Tigran Mkrtchyan
2011-12-02 15:15 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111128170644.GA3105@fieldses.org \
--to=bfields@fieldses.org \
--cc=SteveD@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=tigran.mkrtchyan@desy.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.