linux-kernel - Re: [PATCH] NFS/RDMA: Document separate Kconfig symbols

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 04 Sep 2014 16:28:59 -0700
From:	Randy Dunlap <rdunlap@...radead.org>
To:	Paul Bolle <pebolle@...cali.nl>
CC:	Jeff Layton <jlayton@...hat.com>,
	"J. Bruce Fields" <bfields@...hat.com>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] NFS/RDMA: Document separate Kconfig symbols

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@...cali.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@...cali.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@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/