From: Wendy Cheng Subject: Re: [patch] fix statd -n Date: Mon, 05 May 2008 10:59:02 -0400 Message-ID: <481F20B6.8080603@gmail.com> References: <20080421000214.GA5453@fieldses.org> <24c1515f0804281352u2d04ac89i820dc6807dde39f1@mail.gmail.com> <4817346F.5000101@netapp.com> <20080429161607.GA20420@fieldses.org> <24c1515f0805010557o5daf72f7hc3db5bf85354898e@mail.gmail.com> <24c1515f0805010628k6b57598btb27116c719b99fad@mail.gmail.com> <481B316E.8090800@gmail.com> <24c1515f0805021413u450d8bbcr806a90c327b287a1@mail.gmail.com> <481B96D0.8010802@gmail.com> <24c1515f0805021724q7dfe5294r702a9c8ffde01129@mail.gmail.com> <20080505144538.GB8259@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Cc: Janne Karhunen , Peter Staubach , linux-nfs@vger.kernel.org To: "J. Bruce Fields" Return-path: Received: from mx2.netapp.com ([216.240.18.37]:64157 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753149AbYEEO4t (ORCPT ); Mon, 5 May 2008 10:56:49 -0400 In-Reply-To: <20080505144538.GB8259@fieldses.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: J. Bruce Fields wrote: > On Fri, May 02, 2008 at 08:24:25PM -0400, Janne Karhunen wrote: > >> On Fri, May 2, 2008 at 6:33 PM, Wendy Cheng wrote: >> >> >>> Maybe I mislead you in previous post. The "-H" is only an "example" - to >>> show people how to selectively move an ip address around without affecting >>> other co-existing nfs ip interface on the same server. I did plan to submit >>> a complete user mode patch so the program after "-H" will have a default >>> executable (but user still can use their own if they don't like our nlm >>> directory structure). >>> >> Even if you ship the default executable user would >> still need to go and edit it (add the address). Well, >> I guess it would not be that much harder than >> specifying the -n, but somehow this does seem >> more arcane (for simple setups). >> > > In any case, if there's still a legimate use case for -n, even if it's > not great, we should err on the side of fixing it just to save problems > for anyone with an existing working setup. > > If -n has never worked at all for anyone, then OK, let's get rid of it. > > --b. > Simpler code and consolidated logic flow are always better - would like to vote for its deletion. I had a very bad experience with a filesystem (*cough*) that accepted few mis-understood boundary condition fixes that ended up disturbing the core logic. It still couldn't recover from it and the code churning keeps going on until today. -- Wendy