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

On Thu, Jun 25, 2026, at 1:31 PM, Mike Snitzer wrote:
> 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.

Correct: The Makefile changes are for a target that is used only
when the .x file changes, not for rebuilding the kernel.

However, as far as I am aware the client does not use the xdrgen
headers for anything, currently. Changing the server-side should
be done in a separate patch and only if the server-side code also
needs the new protocol definitions. Otherwise I think we continue
with the duplicated infrastructure -- or only hand-rolled, if
there are no server-side needs yet.


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

We're not that far along with xdrgen. I haven't heard any interest
in the client-side maintainers adopting the tool-generated approach.


-- 
Chuck Lever