On 08/30/2010 01:04 PM, J. Bruce Fields wrote: > On Mon, Aug 30, 2010 at 12:53:16PM -0400, Steve Dickson wrote: >> On 08/30/2010 12:16 PM, Jeff Layton wrote: >>> How this as an alternate proposal? >>> >>> We attempt to mount up nfsdfs. If the "threads" file still isn't >>> present after the attempt, we then log a warning and go with the >>> nfsctl() interface? >> Has anybody test this legacy interface lately?? Does anybody anybody >> depend on the existence of this interface??? I would guess the answer >> would be no to both questions... So I see this as an opportunity so >> simplify the code... which is always a good thing... >> >> So I would have no problem saying from the next release of nfs-utils, >> the legacy interface is no longer supported... especially if there are >> issues with IPV6. > > In general I'd like backwards-compatibility to be a very high priority, > in both directions. (Both continuing to support old nfs-utils in new > kernels, and supporting old kernels with new nfs-utils.) Among other > advantages, it makes it easier to troubleshoot user problems if we don't > have to ask them to upgrade multiple packages at once to test a fix. While I agree backwards-compatibility extremely important, but taking a look at the code, if things like /proc/fs/nfsd/portlist and /proc/fs/nfsd/versions do not exist, I don't see how anything will work. > > On the other hand, the nfsctl interface is pretty old (when did the new > stuff go in, exactly?). Its been a while... > > On the other other hand, Jeff's patch isn't really very complicated. > (Though the amount of additional code we could delete might be large.) Well what guarantees /proc/nfs/nfsd will be mounted after the system() call? There is none plus there is no error checking so if the mount does (silently) fail we are in the same position we are today... I just don't see how the patch moves us forward... steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
