statlite()

[Rob Ross <rross@mcs.anl.gov>]

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.
>