Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> All of these are easily available. But why special case them so that
> userspace must not ask for them? This makes an otherwise totally
> regular interface special now. Note that filesystems could always fill
> it out anyway and set it in the return mask.
Because it would be a waste of bits in the mask. Is there a point in having
bits that are always going to be set unconditionally when we can just
*document* that these few fields are always going to be set.
I'm sure people can cope with the concept that some data are provided
unconditionally and don't have bits and the rest are provided conditionally
and do have bits.
I admit, though, that i_mode is tricky, since it's actually the combination of
two pieces of information - one conditional (permission bits) and one normally
unconditional (file type). Possibly then i_mode should have two flags since I
can think of situations where the file type might be other - reparse points,
automount points.
So yes, you can look on it as there are special cases. However, if I can drop
stat emulation support, everything resolves down to the following classes:
(1) Stuff that's unconditional: st_dev, st_blksize, st_information (maybe).
(2) st_mode & S_IFMT. Unconditional or conditional? I'm not sure.
(3) Stuff that's conditional: st_mode & ~S_IFMT, st_rdev, st_ino, ...
Basically everything else.
David
--
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
