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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 07 Jan 2015 10:22:23 -0800
From:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To:	Sagi Grimberg <sagig@....mellanox.co.il>
Cc:	linux-scsi@...r.kernel.org, target-devel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"Patil, Kiran" <kiran.patil@...el.com>,
	"Minturn, Dave B" <dave.b.minturn@...el.com>
Subject: 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?

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

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ