[SSSD] [PATCH v2 1/5] NEW CLIENT: plugin for NFSv4 rpc.idmapd

Jakub Hrozek jhrozek at redhat.com
Wed Jun 25 06:24:30 UTC 2014


On Tue, Jun 24, 2014 at 04:05:08PM -0400, Simo Sorce wrote:
> On Mon, 2014-06-23 at 09:55 +0200, Jakub Hrozek wrote:
> > On Sun, Jun 22, 2014 at 09:34:54PM -0400, Simo Sorce wrote:
> > > > I would prefer that, yes. 
> > > 
> > > I would prefer not.
> > > 
> > > > I am hoping other SSSD developers would chime in as well so that the
> > > > decision is not a one man party, but I personally prefer the code to
> > > > read consistently. If the socket underneath is a shared NSS one or a
> > > > NFS one is an implementation detail.
> > > 
> > > But it has extremely important consequences on locking and thread
> > > safety, and using aliases, while it may help readability in some areas
> > > can also be quite confusing from the coherency POV.
> > > 
> > > Simo.
> > 
> > OK, what is your proposal?
> 
> To use only one function name to access a pipe. The function refers to
> the communication channel used, not the commands sent on it.
> 
> If you prefer to rename the ..nss.. function to something more abstract,
> that's fine too.
> 
> Simo.

Then I actually, agree, as I wrote previously:

I would expect either:

nss_lock()
do_stuff_with_nss()
nss_unlock()

or s/nss/nfs/ 

So I'm fine with using nss. I don't like renaming the function to something
generic, I would still prefer to see what pipe is used.



More information about the sssd-devel mailing list