From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Becker Subject: Re: Re: GFS, what's remaining Date: Sat, 3 Sep 2005 22:00:26 -0700 Message-ID: <20050904050026.GU8684@ca-server1.us.oracle.com> References: <20050901104620.GA22482@redhat.com> <200509040022.37102.phillips@istop.com> <20050904043000.GQ8684@ca-server1.us.oracle.com> <200509040051.11095.phillips@istop.com> Reply-To: linux clustering Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , ak@suse.de, linux-cluster@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: To: Daniel Phillips Content-Disposition: inline In-Reply-To: <200509040051.11095.phillips@istop.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-cluster-bounces@redhat.com Errors-To: linux-cluster-bounces@redhat.com List-Id: linux-fsdevel.vger.kernel.org On Sun, Sep 04, 2005 at 12:51:10AM -0400, Daniel Phillips wrote: > Clearly, I ought to have asked why dlmfs can't be done by configfs. It is the > same paradigm: drive the kernel logic from user-initiated vfs methods. You > already have nearly all the right methods in nearly all the right places. configfs, like sysfs, does not support ->open() or ->release() callbacks. And it shouldn't. The point is to hide the complexity and make it easier to plug into. A client object should not ever have to know or care that it is being controlled by a filesystem. It only knows that it has a tree of items with attributes that can be set or shown. Joel -- "In a crisis, don't hide behind anything or anybody. They're going to find you anyway." - Paul "Bear" Bryant Joel Becker Senior Member of Technical Staff Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127