Re: Attempt at "stat light" implementation

[Jamie Lokier <jamie@shareable.org>]

Oleg Drokin wrote:
> Hello!
> Sure. When they append to sturct stat, they would add new bits.
> We have 32 bits in the flags, then 3 bits are already used for AT*  
> flags.
> That leaves us with 29 bits for STAT_* (or perhaps AT_STAT) flags, and
> we already use ~15 fields in the struct stat, do we have enough bits,
> or should we increase the flags width right now while we are at it?

I don't see all 31 bits being used up in the foreseeable future.  So
it's fine as long as you (in future) make the last one
__AT_STAT_MORE_FLAGS causing an additional syscall argument to be
interpreted for more flags.  Glibc would wrap it up.

> >Once you have fine-grained selection of stat fields - it's natural to
> >ask why not allow _additional_ stat fields in an future-extensible
> >fashion?  A few things would be handy sometimes, such as inode
> >generation number, modification generation number (to detect changes
> >across reboots), and extra flags indicating COW or other properties.
> 
> >If an "extensible" attribute is not asked for, the kernel must not
> >fill in that field of the structure as the app may be not have
> >allocated space for it.  Or it must use a tag-length-value sort of
> >structure for the result, similar to network CMSGs.
> 
> The app allocates struct stat, whatever it is, I presume. There is a
> huge benefit to actually reuse existing struct stat, I believe.

I agree, but you can't fill in unwanted _additional_ fields if you add
any to the kernel's "struct stat" (or "struct stat_extended" which is
binary compatible but has additional fields).  If you do that, _old_
apps will allocate a smaller structure than the kernel is using.

-- Jamie