From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755503AbaIDX3E (ORCPT ); Thu, 4 Sep 2014 19:29:04 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:37699 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750990AbaIDX3C (ORCPT ); Thu, 4 Sep 2014 19:29:02 -0400 Message-ID: <5408F5BB.1020502@infradead.org> Date: Thu, 04 Sep 2014 16:28:59 -0700 From: Randy Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Paul Bolle CC: Jeff Layton , "J. Bruce Fields" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] NFS/RDMA: Document separate Kconfig symbols References: <1397052353.22767.31.camel@x220> <20140409101322.4968e22c@tlielax.poochiereds.net> <1409873128.5546.139.camel@x220> In-Reply-To: <1409873128.5546.139.camel@x220> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/04/14 16:25, Paul Bolle wrote: > Randy, > > On Wed, 2014-04-09 at 10:13 -0400, Jeff Layton wrote: >> On Wed, 09 Apr 2014 16:05:53 +0200 >> Paul Bolle wrote: >> >>> The NFS/RDMA Kconfig symbol was split into separate options for client >>> and server in commit 2e8c12e1b765 ("xprtrdma: add separate Kconfig >>> options for NFSoRDMA client and server support"). Update the >>> documentation to reflect this split. >>> >>> Signed-off-by: Paul Bolle >>> --- >>> 0) Should Documentation/ describe the current release, or the current >>> and previous releases? For these paragraphs I choose only the current >>> release. >>> >> >> I think they're only relevant for the tree they're in. The docs are shipped >> with the kernel sources, after all, so presumably someone who is >> looking at these has docs that match their kernel (my omission >> notwithstanding, of course) >> >>> 1) Another approach could be to not document the Kconfig setup at all, >>> because the Kconfig system should, in theory, provide all help needed to >>> correctly configure the build for (in this case) NFS/RDMA. But is that >>> true? >>> >> >> Yeah, it does seem somewhat redundant. >> >>> 2) By the way: what's the purpose of INFINIBAND_ADDR_TRANS? >>> >>> Documentation/filesystems/nfs/nfs-rdma.txt | 16 +++++++++------- >>> 1 file changed, 9 insertions(+), 7 deletions(-) >>> >>> diff --git a/Documentation/filesystems/nfs/nfs-rdma.txt b/Documentation/filesystems/nfs/nfs-rdma.txt >>> index e386f7e4bcee..724043858b08 100644 >>> --- a/Documentation/filesystems/nfs/nfs-rdma.txt >>> +++ b/Documentation/filesystems/nfs/nfs-rdma.txt >>> @@ -138,9 +138,9 @@ Installation >>> - Build, install, reboot >>> >>> The NFS/RDMA code will be enabled automatically if NFS and RDMA >>> - are turned on. The NFS/RDMA client and server are configured via the hidden >>> - SUNRPC_XPRT_RDMA config option that depends on SUNRPC and INFINIBAND. The >>> - value of SUNRPC_XPRT_RDMA will be: >>> + are turned on. The NFS/RDMA client and server are configured via the >>> + SUNRPC_XPRT_RDMA_CLIENT and SUNRPC_XPRT_RDMA_SERVER config options that both >>> + depend on SUNRPC and INFINIBAND. The default value of both options will be: >>> >>> - N if either SUNRPC or INFINIBAND are N, in this case the NFS/RDMA client >>> and server will not be built >>> @@ -235,8 +235,9 @@ NFS/RDMA Setup >>> >>> - Start the NFS server >>> >>> - If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in >>> - kernel config), load the RDMA transport module: >>> + If the NFS/RDMA server was built as a module >>> + (CONFIG_SUNRPC_XPRT_RDMA_SERVER=m in kernel config), load the RDMA >>> + transport module: >>> >>> $ modprobe svcrdma >>> >>> @@ -255,8 +256,9 @@ NFS/RDMA Setup >>> >>> - On the client system >>> >>> - If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in >>> - kernel config), load the RDMA client module: >>> + If the NFS/RDMA client was built as a module >>> + (CONFIG_SUNRPC_XPRT_RDMA_CLIENT=m in kernel config), load the RDMA client >>> + module: >>> >>> $ modprobe xprtrdma.ko >>> >> >> Thanks, nice catch, I had forgotten about the docs... >> >> Reviewed-by: Jeff Layton > > It seems nothing ever happened after this. Can you take this patch? Or > should I resend it with Jeff's Reviewed-by added? I can add Jeff's Reviewed-by. I'll merge it. Thanks. -- ~Randy