[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <176896862299.16766.6206046829320088529@noble.neil.brown.name>
Date: Wed, 21 Jan 2026 15:10:22 +1100
From: NeilBrown <neilb@...mail.net>
To: "Jeff Layton" <jlayton@...nel.org>
Cc: "Christoph Hellwig" <hch@...radead.org>,
"Amir Goldstein" <amir73il@...il.com>,
"Christian Brauner" <brauner@...nel.org>,
"Alexander Viro" <viro@...iv.linux.org.uk>,
"Chuck Lever" <chuck.lever@...cle.com>,
"Olga Kornievskaia" <okorniev@...hat.com>,
"Dai Ngo" <Dai.Ngo@...cle.com>, "Tom Talpey" <tom@...pey.com>,
"Hugh Dickins" <hughd@...gle.com>,
"Baolin Wang" <baolin.wang@...ux.alibaba.com>,
"Andrew Morton" <akpm@...ux-foundation.org>,
"Theodore Ts'o" <tytso@....edu>,
"Andreas Dilger" <adilger.kernel@...ger.ca>, "Jan Kara" <jack@...e.com>,
"Gao Xiang" <xiang@...nel.org>, "Chao Yu" <chao@...nel.org>,
"Yue Hu" <zbestahu@...il.com>, "Jeffle Xu" <jefflexu@...ux.alibaba.com>,
"Sandeep Dhavale" <dhavale@...gle.com>,
"Hongbo Li" <lihongbo22@...wei.com>, "Chunhai Guo" <guochunhai@...o.com>,
"Carlos Maiolino" <cem@...nel.org>, "Ilya Dryomov" <idryomov@...il.com>,
"Alex Markuze" <amarkuze@...hat.com>,
"Viacheslav Dubeyko" <slava@...eyko.com>, "Chris Mason" <clm@...com>,
"David Sterba" <dsterba@...e.com>,
"Luis de Bethencourt" <luisbg@...nel.org>,
"Salah Triki" <salah.triki@...il.com>,
"Phillip Lougher" <phillip@...ashfs.org.uk>,
"Steve French" <sfrench@...ba.org>, "Paulo Alcantara" <pc@...guebit.org>,
"Ronnie Sahlberg" <ronniesahlberg@...il.com>,
"Shyam Prasad N" <sprasad@...rosoft.com>,
"Bharath SM" <bharathsm@...rosoft.com>,
"Miklos Szeredi" <miklos@...redi.hu>,
"Mike Marshall" <hubcap@...ibond.com>,
"Martin Brandenburg" <martin@...ibond.com>,
"Mark Fasheh" <mark@...heh.com>, "Joel Becker" <jlbec@...lplan.org>,
"Joseph Qi" <joseph.qi@...ux.alibaba.com>,
"Konstantin Komarov" <almaz.alexandrovich@...agon-software.com>,
"Ryusuke Konishi" <konishi.ryusuke@...il.com>,
"Trond Myklebust" <trondmy@...nel.org>,
"Anna Schumaker" <anna@...nel.org>, "Dave Kleikamp" <shaggy@...nel.org>,
"David Woodhouse" <dwmw2@...radead.org>,
"Richard Weinberger" <richard@....at>, "Jan Kara" <jack@...e.cz>,
"Andreas Gruenbacher" <agruenba@...hat.com>,
"OGAWA Hirofumi" <hirofumi@...l.parknet.co.jp>,
"Jaegeuk Kim" <jaegeuk@...nel.org>, linux-nfs@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-ext4@...r.kernel.org,
linux-erofs@...ts.ozlabs.org, linux-xfs@...r.kernel.org,
ceph-devel@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-cifs@...r.kernel.org, linux-unionfs@...r.kernel.org,
devel@...ts.orangefs.org, ocfs2-devel@...ts.linux.dev,
ntfs3@...ts.linux.dev, linux-nilfs@...r.kernel.org,
jfs-discussion@...ts.sourceforge.net, linux-mtd@...ts.infradead.org,
gfs2@...ts.linux.dev, linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to
nfsd export support
On Mon, 19 Jan 2026, Jeff Layton wrote:
>
> There is another approach we could consider: We could move the
> export_operations that are needed for local filehandle access into a
> new struct filehandle_operations or something. It does mean adding an
> extra pointer to the super_block for the new operations vector, but it
> might be more intuitive.
If that sort of change were seen to be valuable, I would rather not
create a filehandle_operations but merge some (or all) of
export_operations into super_operations.
Maybe then the existence of s_export_op would return to mean "NFS export
supported" even if it is empty.
Thanks,
NeilBrown
Powered by blists - more mailing lists