From: Randy Dunlap <rdunlap@infradead.org>
To: Paul Bolle <pebolle@tiscali.nl>
Cc: Jeff Layton <jlayton@redhat.com>,
"J. Bruce Fields" <bfields@redhat.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] NFS/RDMA: Document separate Kconfig symbols
Date: Thu, 04 Sep 2014 16:28:59 -0700 [thread overview]
Message-ID: <5408F5BB.1020502@infradead.org> (raw)
In-Reply-To: <1409873128.5546.139.camel@x220>
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 <pebolle@tiscali.nl> 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 <pebolle@tiscali.nl>
>>> ---
>>> 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 <jlayton@redhat.com>
>
> 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
prev parent reply other threads:[~2014-09-04 23:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-09 14:05 [PATCH] NFS/RDMA: Document separate Kconfig symbols Paul Bolle
2014-04-09 14:13 ` Jeff Layton
2014-09-04 23:25 ` Paul Bolle
2014-09-04 23:28 ` Randy Dunlap [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5408F5BB.1020502@infradead.org \
--to=rdunlap@infradead.org \
--cc=bfields@redhat.com \
--cc=jlayton@redhat.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pebolle@tiscali.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox