On Feb 21, 2025, at 9:34 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > > We can define some new interface for return what xflags are supported > by a particular file system. This could either be the long-debated, > but never implemented statfsx() system call. Or it could be extending > what gets returned by FS_IOC_GETXATTR by using one of the fs_pad > fields in struct fsxattr. This is arguably the simplest way of > dealing with the problem. > > I suppose the field could double as the bitmask field when > FS_IOC_SETXATTR is called, but that just seems to be an overly complex > set of semantics. If someone really wants to do that, I wouldn't > really complain, but then what we would actually call the field > "flags_supported_on_get_bitmask_on_set" would seem a bit wordy. :-) The nice thing about allowing the bitmask on SET to mean "only set/clear the specified fields" is that this allows a race-free mechanism to change the flags, whereas GET+SET could be racy between two callers. I don't think the two uses are incompatible. If called as GET+SET, where the GET will return the flags+mask, then any flag bits set/cleared should also be in mask when SET, and all of the other bits are reset to the same value. If called as "SET flags+mask" with a limited number of bits, only those bits in mask would be set/cleared, and the other bits would be left as-is. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
