On 2010-07-05, at 08:59, David Howells wrote:
> Michael Kerrisk <mtk.manpages@xxxxxxxxx> wrote:
>
>> * Include information from the "inode_info" structure, most notably
>> i_flags, but perhaps other info as well.
>
> This thought has occurred to me, but are the contents of i_flags identical for
> all filesystems? Certainly, i_flags doesn't seem to match the FS_IOC_GETFLAGS
> mask. For example:
>
> #define FS_SECRM_FL 0x00000001
>
> vs:
>
> #define S_SYNC 1 /* Writes are synced at once */
>
> (1) Does it make sense to rearrange the S_xxxx flags to match the numbers for
> FS_xxxx_FL?
I saw your patch to that effect. I'm of mixed feelings about this, since the S_* flags have traditionally been changed on an ad-hoc basis and I don't necessarily want to let this leak into the on-disk format of these flags for ext*.
One way to ensure that this holds true is to have a compile-time assertion that the respective S_* flags match FS_*_FL and EXT_*_FL.
We use a macro in Lustre for compile-time assertions that depends on the detection of duplicate values in a switch() statement:
/** Compile-time assertion.
* Check an invariant described by a constant expression at compile time by
* forcing a compiler error if it does not hold. @cond must be a constant
* expression as defined by the ISO C Standard:
*
* 6.8.4.2 The switch statement
* ....
* [#3] The expression of each case label shall be an integer
* constant expression and no two of the case constant
* expressions in the same switch statement shall have the same
* value after conversion...
*
*/
#define CLASSERT(cond) do {switch(42) {case (cond): case 0: break;}} while (0)
> (2) Does it make sense to do the BSD st_flags compatibility in userspace?
>
> (3) Can we add a couple more flags to make Samba's life easier? Say an
> archived bit and a hidden bit?
I wouldn't object to that. The BSD flags indicate that the hidden bit should only affect GUI display managers, not "ls".
> (4) Do I actually need to provide a mask saying what st_flags are applicable
> to the file you've just queried?
Hmm, good question.
> (5) How often are these flags required? E.g. does it make more sense to keep
> them as an additional result, or does it make sense to stick them in the
> kstat and xstat structs, knowing that these are allocated on the kernel
> stack maybe as three times if an ecryptfs file?
If they aren't requested by userspace, the cost is mostly irrelevant. I think on OSX these flags are returned for every "ls" call, to mark the inodes with xattrs every time.
Cheers, Andreas
--
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
