[target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?

[target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git nvme_of
head:   40d8c11927282d59855d645b35798edd97828da5
commit: 40d8c11927282d59855d645b35798edd97828da5 [3/3] nvme_of: Initial skeleton commit
reproduce:
  # apt-get install sparse
  git checkout 40d8c11927282d59855d645b35798edd97828da5
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructure                Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild                 Intel Corporation

[PATCH target] nvme_of: nvme_of_fabric_configfs can be static

[kbuild test robot]

drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?

Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
 nvme_of_configfs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/nvme_of/nvme_of_configfs.c b/drivers/target/nvme_of/nvme_of_configfs.c
index c34603c..43a3abc1 100644
--- a/drivers/target/nvme_of/nvme_of_configfs.c
+++ b/drivers/target/nvme_of/nvme_of_configfs.c
@@ -22,7 +22,7 @@
 #include "nvme_of_fabric.h"
 
 /* Local pointer to allocated TCM configfs fabric module */
-struct target_fabric_configfs *nvme_of_fabric_configfs;
+static struct target_fabric_configfs *nvme_of_fabric_configfs;
 
 static struct se_node_acl *nvme_of_make_nodeacl(
 	struct se_portal_group *se_tpg,

Re: [target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?

[Nicholas A. Bellinger]

On Wed, 2015-01-07 at 03:35 +0800, kbuild test robot wrote:
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git nvme_of
> head:   40d8c11927282d59855d645b35798edd97828da5
> commit: 40d8c11927282d59855d645b35798edd97828da5 [3/3] nvme_of: Initial skeleton commit
> reproduce:
>   # apt-get install sparse
>   git checkout 40d8c11927282d59855d645b35798edd97828da5
>   make ARCH=x86_64 allmodconfig
>   make C=1 CF=-D__CHECK_ENDIAN__
> 
> 
> sparse warnings: (new ones prefixed by >>)
> 
> >> drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?
> 
> Please review and possibly fold the followup patch.
> 

Fixed.  Thanks Fengguang!

--nab

Re: [target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?

[Sagi Grimberg]

On 1/7/2015 12:44 AM, Nicholas A. Bellinger wrote:
> On Wed, 2015-01-07 at 03:35 +0800, kbuild test robot wrote:
>> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git nvme_of
>> head:   40d8c11927282d59855d645b35798edd97828da5
>> commit: 40d8c11927282d59855d645b35798edd97828da5 [3/3] nvme_of: Initial skeleton commit
>> reproduce:
>>    # apt-get install sparse
>>    git checkout 40d8c11927282d59855d645b35798edd97828da5
>>    make ARCH=x86_64 allmodconfig
>>    make C=1 CF=-D__CHECK_ENDIAN__
>>
>>
>> sparse warnings: (new ones prefixed by >>)
>>
>>>> drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?
>>
>> Please review and possibly fold the followup patch.
>>
>
> Fixed.  Thanks Fengguang!
>

Hey Nic,

Hope all is well.

So this skeleton is interesting to me. As this is a fabric module I
assume this would be the NVMEoFabrics target mode driver for upstream 
which would be able to talk to NVMEoFabrics initiator (which by
the way makes LIO something more than a SCSI target - will this be 
accepted?).

I'm currently participating in nvmexpress working group defining the
standard of protocol, specifically in the context of RDMA (naturally).

I'm interested in taking an active role in this project, It is
important to build this layered from day one - separating the fabric 
logic (RDMA or FCoE) from the core layer.

Moreover, I know that Mellanox has some plans on accelerating this
area in future devices and we are currently looking into ways to
do that. I want to see that the SW will be able to support that.

So, Thoughts?

Sagi.

Re: [target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?

[Nicholas A. Bellinger]

On Wed, 2015-01-07 at 10:57 +0200, Sagi Grimberg wrote:
> On 1/7/2015 12:44 AM, Nicholas A. Bellinger wrote:
> > On Wed, 2015-01-07 at 03:35 +0800, kbuild test robot wrote:
> >> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git nvme_of
> >> head:   40d8c11927282d59855d645b35798edd97828da5
> >> commit: 40d8c11927282d59855d645b35798edd97828da5 [3/3] nvme_of: Initial skeleton commit
> >> reproduce:
> >>    # apt-get install sparse
> >>    git checkout 40d8c11927282d59855d645b35798edd97828da5
> >>    make ARCH=x86_64 allmodconfig
> >>    make C=1 CF=-D__CHECK_ENDIAN__
> >>
> >>
> >> sparse warnings: (new ones prefixed by >>)
> >>
> >>>> drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?
> >>
> >> Please review and possibly fold the followup patch.
> >>
> >
> > Fixed.  Thanks Fengguang!
> >
> 
> Hey Nic,
> 
> Hope all is well.
> 
> So this skeleton is interesting to me. As this is a fabric module I
> assume this would be the NVMEoFabrics target mode driver for upstream 
> which would be able to talk to NVMEoFabrics initiator (which by
> the way makes LIO something more than a SCSI target - will this be 
> accepted?).
> 

That is currently the plan.

It's still unclear how this will work wrt to existing target code, but
given the amount of logic that NVMe is borrowing from SCSI on the
command set side (PR, ALUA, VAAI, DIF), I'm sure there is an opportunity
for code sharing between NVMe and SCSI based fabrics.

> I'm currently participating in nvmexpress working group defining the
> standard of protocol, specifically in the context of RDMA (naturally).
> 

Glad to hear that your involved.  ;)

> I'm interested in taking an active role in this project, It is
> important to build this layered from day one - separating the fabric 
> logic (RDMA or FCoE) from the core layer.
> 
> Moreover, I know that Mellanox has some plans on accelerating this
> area in future devices and we are currently looking into ways to
> do that. I want to see that the SW will be able to support that.
> 
> So, Thoughts?
> 

FYI, Kiran and Dave (CC'ed) from Intel will be driving upstream NVME-OF
target development.

I'll be primarily focused on figuring out how NVMe and SCSI can play
nicely in target-core, and helping out on the NVMe-OF side where
necessary.

--nab

Re: [target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?

[Sagi Grimberg]

>> On Wed, 2015-01-07 at 10:57 +0200, Sagi Grimberg wrote:
>>> On 1/7/2015 12:44 AM, Nicholas A. Bellinger wrote:
>>>> On Wed, 2015-01-07 at 03:35 +0800, kbuild test robot wrote:
>>>> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git nvme_of
>>>> head:   40d8c11927282d59855d645b35798edd97828da5
>>>> commit: 40d8c11927282d59855d645b35798edd97828da5 [3/3] nvme_of: Initial skeleton commit
>>>> reproduce:
>>>>   # apt-get install sparse
>>>>   git checkout 40d8c11927282d59855d645b35798edd97828da5
>>>>   make ARCH=x86_64 allmodconfig
>>>>   make C=1 CF=-D__CHECK_ENDIAN__
>>>> 
>>>> 
>>>> sparse warnings: (new ones prefixed by >>)
>>>> 
>>>>>> drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?
>>>> 
>>>> Please review and possibly fold the followup patch.
>>> 
>>> Fixed.  Thanks Fengguang!
>> 
>> Hey Nic,
>> 
>> Hope all is well.
>> 
>> So this skeleton is interesting to me. As this is a fabric module I
>> assume this would be the NVMEoFabrics target mode driver for upstream 
>> which would be able to talk to NVMEoFabrics initiator (which by
>> the way makes LIO something more than a SCSI target - will this be 
>> accepted?).
> 
> That is currently the plan.
> 
> It's still unclear how this will work wrt to existing target code, but
> given the amount of logic that NVMe is borrowing from SCSI on the
> command set side (PR, ALUA, VAAI, DIF), I'm sure there is an opportunity
> for code sharing between NVMe and SCSI based fabrics.

Right, but I assume there will be a different method to provision this stuff given that the target exposes NVME SQs.

> 
>> I'm currently participating in nvmexpress working group defining the
>> standard of protocol, specifically in the context of RDMA (naturally).
> 
> Glad to hear that your involved.  ;)

Should say passively involved, at the moment I'm just following this stuff.

> 
>> I'm interested in taking an active role in this project, It is
>> important to build this layered from day one - separating the fabric 
>> logic (RDMA or FCoE) from the core layer.
>> 
>> Moreover, I know that Mellanox has some plans on accelerating this
>> area in future devices and we are currently looking into ways to
>> do that. I want to see that the SW will be able to support that.
>> 
>> So, Thoughts?
> 
> FYI, Kiran and Dave (CC'ed) from Intel will be driving upstream NVME-OF
> target development.
> 
> I'll be primarily focused on figuring out how NVMe and SCSI can play
> nicely in target-core, and helping out on the NVMe-OF side where
> necessary.

Is there something open that I can start playing around with? What is the status here? I imagine that the initiator is developed as well...

Cheers,
Sagi.

Re: [target:nvme_of 3/3] drivers/target/nvme_of/nvme_of_configfs.c:25:31: sparse: symbol 'nvme_of_fabric_configfs' was not declared. Should it be static?

[Nicholas A. Bellinger]

On Wed, 2015-01-07 at 22:26 +0200, Sagi Grimberg wrote:
> >> On Wed, 2015-01-07 at 10:57 +0200, Sagi Grimberg wrote:
> >>> On 1/7/2015 12:44 AM, Nicholas A. Bellinger wrote:

<SNIP>

> >> Hey Nic,
> >> 
> >> Hope all is well.
> >> 
> >> So this skeleton is interesting to me. As this is a fabric module I
> >> assume this would be the NVMEoFabrics target mode driver for upstream 
> >> which would be able to talk to NVMEoFabrics initiator (which by
> >> the way makes LIO something more than a SCSI target - will this be 
> >> accepted?).
> > 
> > That is currently the plan.
> > 
> > It's still unclear how this will work wrt to existing target code, but
> > given the amount of logic that NVMe is borrowing from SCSI on the
> > command set side (PR, ALUA, VAAI, DIF), I'm sure there is an opportunity
> > for code sharing between NVMe and SCSI based fabrics.
> 
> Right, but I assume there will be a different method to provision this
> stuff given that the target exposes NVME SQs.
> 

Yeah, it's not clear how this is going to work yet, but I'd expect a new
backend driver will be required for exposing NVMe hardware queues into
target -> fabric driver code.

> > 
> >> I'm currently participating in nvmexpress working group defining the
> >> standard of protocol, specifically in the context of RDMA (naturally).
> > 
> > Glad to hear that your involved.  ;)
> 
> Should say passively involved, at the moment I'm just following this
> stuff.
> 
> > 
> >> I'm interested in taking an active role in this project, It is
> >> important to build this layered from day one - separating the fabric 
> >> logic (RDMA or FCoE) from the core layer.
> >> 
> >> Moreover, I know that Mellanox has some plans on accelerating this
> >> area in future devices and we are currently looking into ways to
> >> do that. I want to see that the SW will be able to support that.
> >> 
> >> So, Thoughts?
> > 
> > FYI, Kiran and Dave (CC'ed) from Intel will be driving upstream NVME-OF
> > target development.
> > 
> > I'll be primarily focused on figuring out how NVMe and SCSI can play
> > nicely in target-core, and helping out on the NVMe-OF side where
> > necessary.
> 
> Is there something open that I can start playing around with? What is
> the status here? I imagine that the initiator is developed as well...
> 

I don't believe any public code is available yet, and considering the
draft spec is only available to members of the NVMe consortium, it's
likely going to be a while before that happens.

However, Dave mentioned off-list that sharing early code amongst NVMe
consortium members should not be an issue.

--nab