> It is not the right usage of the MNT_ flags. They are for feature > controlling, not for the feature reporting.
That is not the case today (MNT_LOCAL, MNT_QUOTA, MNT_ROOTFS, MNT_USER, etc.). I also would like this to become true at some point. > VOP_PATHCONF() is exactly for reporting some mnt features. No, it is to report features that depend on a path. It can be (ab)used to report mount features (calling it on any file inside the mount), but that obfuscates the fact that an information is per-mount, whereas statfs()/statvfs() are exactly designed for per-mount information. > Also, this namespace should not be used frivolously, we already had to > extend flags to 64bit, and again we are not too far from exhausting it. I don't disagree. That said, at some point, we'll have to dodge the bullet, including separating control flags from report ones in the MNT_* namespace (and provide compat' functionality), and probably extending control flags with a second 64-bit field. I suspected from the start that that was the main reason behind you recommending VOP_PATHCONF(). My point here is that it is a slightly non-optimal design choice (as explained just above) that will stay and was made out of a practical issue that anyway will have to be solved at some point, and I find this a bit unfortunate. Solving the issue now is certainly much more work, and in any case I didn't mean to object to not doing it now. But if someone(tm) wants to do it now, that would be great (perhaps me, but not sure yet). Regards. -- Olivier Certner
signature.asc
Description: This is a digitally signed message part.
