Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support
Christoph Hellwig <[email protected]>
| Newsgroups | dev.linux.lists.gfs2,dev.linux.lists.ntfs3,dev.linux.lists.ocfs2-devel,net.sourceforge.lists.linux-f2fs-devel,org.infradead.lists.linux-mtd,org.kernel.vger.ceph-devel,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-cifs,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.kernel.vger.linux-nilfs,org.kernel.vger.linux-unionfs,org.kernel.vger.linux-xfs,org.kvack.linux-mm,org.ozlabs.lists.linux-erofs |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Jan 19, 2026 at 06:22:42PM +1100, NeilBrown wrote: > We are calling it for it's only use. If there was ever another use, we > could change the name if that made sense. It is not a public name, it > is easy to change. No, it is not the only use. This flag needs to be propagate to userspace through statx or the file attrs. As I said before there is plenty of code in userspace that does rely on the traditional file handle semantics. > > Remember nfs also support volatile file handles, and other applications > > might rely on this (I know of quite a few user space applications that > > do, but they are kinda hardwired to xfs anyway). > > The NFS protocol supports volatile file handles. knfsd does not. > So maybe > EXPORT_OP_NOT_NFSD_COMPATIBLE > might be better. or EXPORT_OP_NOT_LINUX_NFSD_COMPATIBLE. > (I prefer opt-out rather than opt-in because nfsd export was the > original purpose of export_operations, but it isn't something > I would fight for) Again, stop trying to name things of the initial user. Flag needs to describe smenatics, not users.