Re: [PATCH 1/4] nfs4.2: add nfs4_2.x to generate the UNCACHEABLE_FILE_DATA attribute

On Thu, Jun 25, 2026 at 10:26:22AM -0400, Anna Schumaker wrote:
> Hi Mike,
> 
> On Wed, Jun 24, 2026, at 3:17 PM, Mike Snitzer wrote:
> > Introduce Documentation/sunrpc/xdr/nfs4_2.x for NFSv4.2 protocol
> > extensions and define the UNCACHEABLE_FILE_DATA attribute (attr 87)
> > there, verbatim from draft-ietf-nfsv4-uncacheable-files Section 7:
> >
> >   typedef bool            fattr4_uncacheable_file_data;
> >   const FATTR4_UNCACHEABLE_FILE_DATA      = 87;
> >
> > This mirrors how the sibling NFSv4.2 attributes (FATTR4_OFFLINE=83,
> > FATTR4_TIME_DELEG_*=84/85, FATTR4_OPEN_ARGUMENTS=86) are defined in
> > Documentation/sunrpc/xdr/nfs4_1.x and generated by
> > tools/net/sunrpc/xdrgen into <linux/sunrpc/xdrgen/nfs4_1.h>, which
> > nfs4.h already includes.
> >
> > Wire the fs/nfsd "make xdrgen" target to generate the definitions header
> > <linux/sunrpc/xdrgen/nfs4_2.h> and include it from <linux/nfs4.h>, so the
> > generated FATTR4_UNCACHEABLE_FILE_DATA constant and the
> > NFS4_fattr4_uncacheable_file_data_sz size macro are available to the
> > NFSv4.2 client support that follows.
> 
> Aren't these client side changes? The xdrgen stuff is used on the
> server-side. I wouldn't expect any of these values to be available
> if nfsd is kconfig-ed off.

The NFS4.x client code needs and has access to NFS spec definitions
also, via <linux/nfs4.h>.

Its only that the server side's xdrgen framework is needed to generate
updates to the headers.  So you'll note that I have also included in
this commit the gnerated output of <linux/sunrpc/xdrgen/nfs4_2.h>.
Even if NFSD weren't Kconfig'd on, the NFS client code still has the
benefit of these NFS spec definitions via <linux/nfs4.h> (and its
inclusion of previously generated <linux/sunrpc/xdrgen/nfs4_1.h> and
now <linux/sunrpc/xdrgen/nfs4_2.h>).

Getting xdrgen to build and verify it to work took effort (Chuck uses
recent Fedora AFAIK, I happen to be using EL9.6 in this container, but
Claude code helped me cut through the missing deps pretty quickly).

So to be clear: the Linux kernel build (and NFS client build) isn't
dependent on xdrgen running at build time.

Tangential but related: maybe the xdrgen stuff should get lifted to
fs/nfs_common/ ?  Or we're fine with it living with NFS server?

Thanks,
Mike