Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp14499154ybl; Mon, 30 Dec 2019 11:13:15 -0800 (PST) X-Google-Smtp-Source: APXvYqykZfClHWWzdykfe3R/btC+swgOA7s02EleuI0MzOFgV1oLPD6m7JV8R5ai+ooxyXvYKcuv X-Received: by 2002:a9d:600e:: with SMTP id h14mr73725877otj.113.1577733195399; Mon, 30 Dec 2019 11:13:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577733195; cv=none; d=google.com; s=arc-20160816; b=rews9p9ZPHWjHgEOfMOzY2ZH3JGPV3cfi3k1KPSy3jb7LWq3rerwZaP+K+zYjLfKzZ KwX2/wFVCENnjSh+CmK5mqJgeY3FckJvEub+chEXkHCFv7JlHysGLuyb5j2W9JN6bicA lHA44XXz+KTW5gd2eRFwrsLZlQBDRws9xxlnzS+/wjnkT/y9zfRFEg+S+R79ZjwFDEAG qvr4d5GMFOoao3WtxBLoL8h+7WUjjz1QQpdVpgrZJ96l/6qzo8wp4WMBr0E09gQDAiP5 Af84YsoF8TDtVR53LDqD863zoCy6Yrrz+NUZg+vh0sMpA3wp8YiWOyW5N5tVnUYg9FuV snjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=viVpPMCMqE4j6zuTKLIXmP2Eyu3edE8bS9bJEBW1IYI=; b=AYJem7zUQlOgjgdFsxj0O94hLdk/zaBYhFRToI4LNmaUL6kSd6fw15LrzboMdLwM9/ +ccHAfwLKLlj+74CVdsxKq/+L1tcTzuKARP1LkuvqCJgsGOl3CUQkyof0+d5FhN//6vw bfSrWPiGDJnUQJlOl+bPuN8UQimXp36PQmCwJl8bFs025aVLalOqr4gwhhKxi8+lF1Ll wt7TbCsOX4gxEI9SbuVQcuqQ5BheWivwy20NuQROJBQBOk0tpYzeIu26TrQXGD5Lyyu+ 9GqBTym74YqKaJDvJoWjQL8WXGLEOsCrAZ+vDNfoH/ZXsvezS0FVy9dI9rKfpDsQ3LHt GU9g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q7si20948617otn.108.2019.12.30.11.13.03; Mon, 30 Dec 2019 11:13:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727642AbfL3TM1 (ORCPT + 99 others); Mon, 30 Dec 2019 14:12:27 -0500 Received: from ms.lwn.net ([45.79.88.28]:60510 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727278AbfL3TM0 (ORCPT ); Mon, 30 Dec 2019 14:12:26 -0500 Received: from lwn.net (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id 80B74536; Mon, 30 Dec 2019 19:12:25 +0000 (UTC) Date: Mon, 30 Dec 2019 12:12:24 -0700 From: Jonathan Corbet To: "Daniel W. S. Almeida" Cc: mchehab+samsung@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, skhan@linuxfoundation.org, linux-kernel-mentees@lists.linuxfoundation.org Subject: Re: [PATCH v2 1/8] Documentation: convert nfs.txt to ReST Message-ID: <20191230121224.1d9e795a@lwn.net> In-Reply-To: References: Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Dec 2019 01:55:55 -0300 "Daniel W. S. Almeida" wrote: > From: "Daniel W. S. Almeida" > > This patch converts nfs.txt to RST. It also moves it to admin-guide. > The reason for moving it is because this document contains information > useful for system administrators, as noted on the following paragraph: > > 'The purpose of this document is to provide information on some of the > special features of the NFS client that can be configured by system > administrators'. > > Signed-off-by: Daniel W. S. Almeida This generally looks good, I just have one request... > Documentation/admin-guide/index.rst | 1 + > Documentation/admin-guide/nfs/index.rst | 9 ++ > .../nfs/nfs-client.rst} | 91 ++++++++++--------- > 3 files changed, 58 insertions(+), 43 deletions(-) > create mode 100644 Documentation/admin-guide/nfs/index.rst > rename Documentation/{filesystems/nfs/nfs.txt => admin-guide/nfs/nfs-client.rst} (72%) > > diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst > index 4405b7485312..4433f3929481 100644 > --- a/Documentation/admin-guide/index.rst > +++ b/Documentation/admin-guide/index.rst > @@ -76,6 +76,7 @@ configure specific aspects of kernel behavior to your liking. > device-mapper/index > efi-stub > ext4 > + nfs/index > gpio/index > highuid > hw_random > diff --git a/Documentation/admin-guide/nfs/index.rst b/Documentation/admin-guide/nfs/index.rst > new file mode 100644 > index 000000000000..f5c0180f4e5e > --- /dev/null > +++ b/Documentation/admin-guide/nfs/index.rst > @@ -0,0 +1,9 @@ > +============= > +NFS > +============= > + > +.. toctree:: > + :maxdepth: 1 > + > + nfs-client > + > diff --git a/Documentation/filesystems/nfs/nfs.txt b/Documentation/admin-guide/nfs/nfs-client.rst > similarity index 72% > rename from Documentation/filesystems/nfs/nfs.txt > rename to Documentation/admin-guide/nfs/nfs-client.rst > index f2571c8bef74..f01bf6a6c207 100644 > --- a/Documentation/filesystems/nfs/nfs.txt > +++ b/Documentation/admin-guide/nfs/nfs-client.rst > @@ -1,3 +1,6 @@ > +========== > +NFS Client > +========== > > The NFS client > ============== > @@ -59,10 +62,11 @@ The DNS resolver > > NFSv4 allows for one server to refer the NFS client to data that has been > migrated onto another server by means of the special "fs_locations" > -attribute. See > - http://tools.ietf.org/html/rfc3530#section-6 > -and > - http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00 > +attribute. See `RFC3530 Section 6: Filesystem Migration and Replication`_ and > +`Implementation Guide for Referrals in NFSv4`_. > + > +.. _RFC3530 Section 6\: Filesystem Migration and Replication: http://tools.ietf.org/html/rfc3530#section-6 > +.. _Implementation Guide for Referrals in NFSv4: http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00 > > The fs_locations information can take the form of either an ip address and > a path, or a DNS hostname and a path. The latter requires the NFS client to > @@ -72,16 +76,16 @@ upcall to allow userland to provide this service. > Assuming that the user has the 'rpc_pipefs' filesystem mounted in the usual > /var/lib/nfs/rpc_pipefs, the upcall consists of the following steps: > > - (1) The process checks the dns_resolve cache to see if it contains a > + #. The process checks the dns_resolve cache to see if it contains a It really only occurs to me now that we probaby shouldn't use the "#" notation. If we truly need an *enumerated* list, meaning that the numbers are an important part of reading the list, then we should retain the numbers in the plain-text version, even if that means we occasionally have to change them if the list changes. If, instead, the numbers aren't important, we should just use bullets instead. In this case, we have an explicit sequence of events, so the numbers should probably remain. Thanks, jon