From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [RFC] POSIX ACL kernel infrastructure Date: Fri, 9 Aug 2002 13:32:46 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20020809133246.B9622@infradead.org> References: <200208041546.35234.agruen@suse.de> <200208091253.55935.agruen@suse.de> <20020809121502.A8178@infradead.org> <200208091422.49879.agruen@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Nathan Scott , Linux-FSDevel , Olaf Kirch , Chris Mason , Jeff Mahoney Return-path: To: Andreas Gruenbacher Content-Disposition: inline In-Reply-To: <200208091422.49879.agruen@suse.de>; from agruen@suse.de on Fri, Aug 09, 2002 at 02:22:49PM +0200 List-Id: linux-fsdevel.vger.kernel.org On Fri, Aug 09, 2002 at 02:22:49PM +0200, Andreas Gruenbacher wrote: > I read this as `Why are you not returning the permissions nfsd should see in > struct, which the inode->getattr IOP fills?'. Please correct me if this is > not what you wanted to say. I meant adding an acl field to struct kstat that is supposed to be filled by ->getattr. > The usual callers of getattr should see the unmasked permissions; it's only > nfsd that needs this special treatment, and only on filesystems that have > ACLs enabled. The getattr IOP is used by others as well. So why the is a new IOP better in that respect? > If you had adding an extra field to struct kstat in mind, this just seems too > intrusive to me for solving the nfsd problem. The problem will go away in the > future when all NFSv3 clients are using the ACCESS RPC, anyway. It's just a > hack right now. So you want to add two inode operations for a hack that is only needed to support old NFS clients? Do you have any profiling data that shows major overhead when going through the xattr layer?