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