From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0FC8A1C695 for ; Thu, 25 Jun 2026 17:31:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782408685; cv=none; b=rt4UCjhjlwa38wEHxePEwdMAvkjY3yHsb0MWMnRUj7+/SNPOPI8B98MxTOQyS3iXosOe/Q3rtHKBiG7fZeE+lgvuAFhNqU8DN+WuAiHZ8elA6lIfeLd3iaGlbhSdM+V2Gn/npdBqtWRDQ2lxzCasHRu1UWQ0F4cW7ju069PIWV0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782408685; c=relaxed/simple; bh=c2lU4rMq1FEMAcA/hCAZMuBdxfd4KcxtaA3stXyJjZY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CDlxP3CfY35uY4V2PYDnaVWP8mIrjoOUvtSFkXfVlHmuRQ/kloY43sEg6+oK0tokO4p2gSqwyVzFRh/XqpTfX8WhaaUhN9NKV78y4wVTAuuaDGNFlQnmEITKjSRSsKpSaHPtY/fQlOV3IMlE1YdLfnC06oDeImXSGTGoxNfwIis= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JyWz/so9; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JyWz/so9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5E9B1F000E9; Thu, 25 Jun 2026 17:31:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782408683; bh=N1pf2ISjatJU5GZKzU5itdhJRp/l3uYrDfSTynbQagk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=JyWz/so9Juv5puVkFhRzt1XbILSx0zmGJUlAWFZvfMxkgN8c4XrNB6UcJ5qcuiZAZ wuvCPbT5VDhyr9SZ6n5DqYLHLrTjbFGA7HAnGyZ8ifxkR2CqvuloyTBWGExbMX9XKU yMQyiB9I/GEu0GEj40uXLKbG0Fw2+zE16CmOH0N1CVExkTH8fVQNDUFJj/3127/8Oe iM+YcONSb5XrnwlFjnRjZ72KfGKxmJVE2dShUZqxSsu/jtYMC0Eyr4hJss+ZL7zNQM 1UTEdw0iX+BWccqit/VvIYz5KH+HS6VKYskFq9akUSajM39tBEdN6aOTix1BCsDhWN QeqdgfS+Cklkw== Date: Thu, 25 Jun 2026 13:31:22 -0400 From: Mike Snitzer To: Anna Schumaker Cc: Trond Myklebust , Tom Haynes , Chuck Lever , linux-nfs@vger.kernel.org Subject: Re: [PATCH 1/4] nfs4.2: add nfs4_2.x to generate the UNCACHEABLE_FILE_DATA attribute Message-ID: References: <20260624191706.72544-1-snitzer@kernel.org> <20260624191706.72544-2-snitzer@kernel.org> <16ff281b-f776-4e6c-9f2a-83c03f0d6eae@app.fastmail.com> Precedence: bulk X-Mailing-List: linux-nfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16ff281b-f776-4e6c-9f2a-83c03f0d6eae@app.fastmail.com> 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 , which > > nfs4.h already includes. > > > > Wire the fs/nfsd "make xdrgen" target to generate the definitions header > > and include it from , 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 . 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 . Even if NFSD weren't Kconfig'd on, the NFS client code still has the benefit of these NFS spec definitions via (and its inclusion of previously generated and now ). 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