On Thursday January 3, [EMAIL PROTECTED] wrote: > On Fri, Dec 21, 2007 at 11:51:47AM -0600, Tom Tucker wrote: > > > > On Fri, 2007-12-14 at 19:03 -0500, J. Bruce Fields wrote: > > > On Tue, Dec 11, 2007 at 05:33:18PM -0600, Tom Tucker wrote: > > > > > > > > Create a transport independent version of the svc_sock_names function. > > > > > > > > The toclose capability of the svc_sock_names service can be implemented > > > > using the svc_xprt_find and svc_xprt_close services. > > > > > > Should we delete the toclose checks from svc_sock_names(), then, under > > > the assumption it's always called with toclose non-NULL now? > > > > > > And why can't we just completely replace svc_sock_names() at this point? > > > > > > > IMO we could, but there is currently a difference in behavior between > > svc_sock_names and svc_find_xprt/close. svc_find_xprt doesn't care what > > the IP address is, it only compares transport name, address family and > > port. > > > > Presently in NFS, we only ever listen on zero, but you can destroy an > > endpoint on a particular interface (IP address). Can anyone shed some > > light on why this is? > > Dunno. Neil?
The "-H" option to "rpc.nfsd" allow you to bind nfsd to a specific interface. I don't think any user-space tools current allow you to unbind a specific interface, but I wouldn't want to lose that functionality. Why are we changing this. Clear the toclose functionality of the svc_sock_names service can *NOT* be impletemented using svc_xprt_find and svc_xprt_close as _find_ doesn't check the port - so just leave things the way they are??? I haven't really been following this update much so maybe there is something I'm missing.... NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
