On Mon, Jan 21, 2019 at 11:35 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Mon, Jan 21, 2019 at 12:54:25AM +0000, Phillip Potter wrote: > > These patches mostly no longer include compile-time checks to ensure > > the filesystem specific on-disk bits are equivalent to the common > > implementation FT_* bits, and instead op to remove the filesystem > > specific definitions entirely where possible, as a result of the > > referenced discussion above. > > > > With the ext4 patch, the EXT4_FT_* definitions are instead defined > > to be FT_*, to give less code churn with the same result (no need > > to modify fs/ext4/namei.c). Also, the nilfs2 and btrfs filesystems > > keep their filesystem specific definitions in the include/uapi/linux > > directory, so these cannot be changed trivially without breaking > > userspace. For this reason, the compile time checks remain in these > > two filesystems. > > Just because something is exposed through the uapi directory today > doesn't mean userspace actually uses it. For example, > https://codesearch.debian.net/search?q=BTRFS_FT_DIR > > The only code which uses the filetype defines is going to be code which > actually looks at a raw filesystem image. All three examples of userspace > code in Debian have their own definitions instead of using the one which > the kernel provides. That's a good point, but I think we should let btrfs developers choose where and how to change the definitions. Probably the ext4 example (patch 7) would be the best to follow, as btrfs also uses some non common constants (BTRFS_FT_MAX, BTRFS_FT_XATTR) that do not map to the common DT_* values. Thanks, Amir.
