From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Wed, 29 Nov 2006 09:14:25 +0000 Message-ID: <20061129091425.GA20693@infradead.org> References: <6.2.3.4.2.20061127213243.04f786c0@cic-mail.lanl.gov> <20061128055428.GA29891@infradead.org> <20061129090450.GA16296@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:22749 "EHLO pentafluge.infradead.org") by vger.kernel.org with ESMTP id S966444AbWK2JO0 (ORCPT ); Wed, 29 Nov 2006 04:14:26 -0500 To: Gary Grider Content-Disposition: inline In-Reply-To: <20061129090450.GA16296@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Nov 29, 2006 at 09:04:50AM +0000, Christoph Hellwig wrote: > - statlite > > The concept generally makes sense. The specified details are however > very wrong. Any statlite call should operate on the normal > OS-specified stat structure and have the mask of flags as an > additional argument. Because of that you can only specific > existing posix stat values as mandatory, but we should have an > informal agreement that assigns unique mask values to extensions. > This allows applications to easily fall back to stat on operating > systems not supporting the flags variant, and also allows new > operating systems to implement stat using the flags variant. > While we're at it statlight is a really bad name for this API, > following that *at APIs it should probably be {l,f,}statf. Just thinking about the need to add another half a dozend syscalls for this. What about somehow funneling this into the flags argument of the {f,l,}statat syscalls?