Hello!
On Apr 7, 2009, at 1:32 PM, Jamie Lokier wrote:
Oleg Drokin wrote:
I have separated stat fields into arbitrary categories based on my
idea of how this needs to be done,
that could of course be refined in other ways if desired.
Type should get its own category - which is finer grained than mode.
Type (dir, file, link, etc.) is sometimes a lot cheaper than the other
attributes to get, because on some filesystems you don't need to read
the inode to get the type. See readdir() and d_type.
Sure. In fact I not believe a flag per field would be the way.
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.
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?
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.
Thanks.
Bye,
Oleg
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
