Re: Attempt at "stat light" implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello!

On Apr 7, 2009, at 1:54 PM, Jamie Lokier wrote:
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.

If the actual struct stat is extended, then it is extended and we
would create additional syscalls to fill the new one anyway.
Of course it would be possible to just extend the *stat_light interface
with caring about what size of the stat_struct version to fill in
the future, but since there are no such fields yet, there is nothing
to code at the moment.

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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux