From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Ross Subject: statlite() Date: Thu, 14 Dec 2006 17:58:32 -0600 Message-ID: <4581E528.7000901@mcs.anl.gov> References: <1164984094.5761.86.camel@lade.trondhjem.org> <20061203015203.GA5656@schatzie.adilger.int> <20061204073200.GB5637@schatzie.adilger.int> <1165245336.711.176.camel@lade.trondhjem.org> <4574C48A.8030007@mcs.anl.gov> <1165298200.5776.26.camel@lade.trondhjem.org> <20061205100748.GC5871@infradead.org> <4575E9B0.3060908@mcs.anl.gov> <20061205220538.GA1988@infradead.org> <45760702.6040805@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , Trond Myklebust , Andreas Dilger , Sage Weil , Brad Boyer , Anton Altaparmakov , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mailgw.mcs.anl.gov ([140.221.9.4]:40173 "EHLO mailgw.mcs.anl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752028AbWLNX6z (ORCPT ); Thu, 14 Dec 2006 18:58:55 -0500 To: Ulrich Drepper In-Reply-To: <45760702.6040805@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org We're going to clean the statlite() call up based on this (and subsequent) discussion and post again. Thanks! Rob Ulrich Drepper wrote: > Christoph Hellwig wrote: >> Ulrich, this in reply to these API proposals: > > I know the documents. The HECWG was actually supposed to submit an > actual draft to the OpenGroup-internal working group but I haven't seen > anything yet. I'm not opposed to getting real-world experience first. > > >>> So other than this "lite" version of the readdirplus() call, and this >>> idea of making the flags indicate validity rather than accuracy, are >>> there other comments on the directory-related calls? I understand >>> that they might or might not ever make it in, but assuming they did, >>> what other changes would you like to see? > > I don't think an accuracy flag is useful at all. Programs don't want to > use fuzzy information. If you want a fast 'ls -l' then add a mode which > doesn't print the fields which are not provided. Don't provide outdated > information. Similarly for other programs. > > >> statlite needs to separate the flag for valid fields from the actual >> stat structure and reuse the existing stat(64) structure. stat lite >> needs to at least get a better name, even better be folded into *statat*, >> either by having a new AT_VALID_MASK flag that enables a new >> unsigned int valid argument or by folding the valid flags into the AT_ >> flags. > > Yes, this is also my pet peeve with this interface. I don't want to > have another data structure. Especially since programs might want to > store the value in places where normal stat results are returned. > > And also yes on 'statat'. I strongly suggest to define only a statat > variant. In the standards group I'll vehemently oppose the introduction > of yet another superfluous non-*at interface. > > As for reusing the existing statat interface and magically add another > parameter through ellipsis: no. We need to become more type-safe. The > userlevel interface needs to be a new one. For the system call there is > no such restriction. We can indeed extend the existing syscall. We > have appropriate checks for the validity of the flags parameter in place > which make such calls backward compatible. > > > >> I think having a stat lite variant is pretty much consensus, we just need >> to fine tune the actual API - and of course get a reference >> implementation. >> So if you want to get this going try to implement it based on >> http://marc.theaimsgroup.com/?l=linux-fsdevel&m=115487991724607&w=2. >> Bonus points for actually making use of the flags in some filesystems. > > I don't like that approach. The flag parameter should be exclusively an > output parameter. By default the kernel should fill in all the fields > it has access to. If access is not easily possible then set the bit and > clear the field. There are of course certain fields which always should > be added. In the proposed man page these are already identified (i.e., > those before the st_litemask member). > > >> At the actual >> C prototype level I would rename d_stat_err to d_stat_errno for >> consistency >> and maybe drop the readdirplus() entry point in favour of readdirplus_r >> only - there is no point in introducing new non-reenetrant APIs today. >