move iscsi to a better place in Kconfig
PATCH 1/1 move iscsi to a better place in Kconfig
Now it looks like we'll have multiple users of the iscsi transport class, the iscsi initiator shouldn't really be a dependency of it. This patch moves iscsi to being an initiator in its own right which selects the transport attributes.
James
drivers/scsi/Kconfig +7 -6
@@ -235,12 +235,18 @@ config SCSI_ISCSI_ATTRS each attached iSCSI device to sysfs, say Y. Otherwise, say N. +endmenu + +menu "SCSI low-level drivers" + depends on SCSI!=n + config ISCSI_TCP tristate "iSCSI Initiator over TCP/IP" - depends on SCSI && INET && SCSI_ISCSI_ATTRS + depends on SCSI && INET select CRYPTO select CRYPTO_MD5 select CRYPTO_CRC32C + select SCSI_ISCSI_ATTRS help The iSCSI Driver provides a host with the ability to access storage through an IP network. The driver uses the iSCSI protocol to transport
@@ -258,11 +264,6 @@ config ISCSI_TCP http://linux-iscsi.sf.net -endmenu - -menu "SCSI low-level drivers" - depends on SCSI!=n - config SGIWD93_SCSI tristate "SGI WD93C93 SCSI Driver" depends on SGI_IP22 && SCSI
Quoted 4 lines · James Bottomley
Now it looks like we'll have multiple users of the iscsi transport class, the iscsi initiator shouldn't really be a dependency of it. This patch moves iscsi to being an initiator in its own right which selects the transport attributes.
I think the reason it was a dependency was becuase the transport class manages does the lifetime management/refcounting for the initiators/iscsi_tcp.c session struct. scsi_transport_iscsi allocates the scsi_host, and the initiator/iscsi_tcp.c's session structure is allocated in that host_data.
Quoted 44 lines
James
drivers/scsi/Kconfig +7
-7@@ -235,12 +235,18 @@ config SCSI_ISCSI_ATTRS each attached iSCSI device to sysfs, say Y. Otherwise, say N. +endmenu + +menu "SCSI low-level drivers" + depends on SCSI!=n + config ISCSI_TCP tristate "iSCSI Initiator over TCP/IP" - depends on SCSI && INET && SCSI_ISCSI_ATTRS + depends on SCSI && INET select CRYPTO select CRYPTO_MD5 select CRYPTO_CRC32C + select SCSI_ISCSI_ATTRS help The iSCSI Driver provides a host with the ability to access storage through an IP network. The driver uses the iSCSI protocol to transport@@ -258,11 +264,6 @@ config ISCSI_TCP http://linux-iscsi.sf.net -endmenu - -menu "SCSI low-level drivers" - depends on SCSI!=n - config SGIWD93_SCSI tristate "SGI WD93C93 SCSI Driver" depends on SGI_IP22 && SCSI -To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Mike Christie
I think the reason it was a dependency was becuase the transport class manages does the lifetime management/refcounting for the
initiators/iscsi_tcp.csession struct.scsi_transport_iscsiallocates thescsi_host, and the initiator/iscsi_tcp.c's session structure is allocated in thathost_data.
Yes, but Kconfig isn't about lifetimes or, in fact, much of the way the code is constructed; it's about how the user selects particular features.
In the current setup, they have to know to say Y/M to the ISCSI attribute question even to see the config option for the iscsi initiator. This is a bit counter intuitive (and definitely isn't the way any of the other drivers that depend on transport classes are presented).
James
Quoted 9 lines · James Bottomley
Quoted 1 line · Mike Christie
I think the reason it was a dependency was becuase the transport class manages does the lifetime management/refcounting for the
initiators/iscsi_tcp.csession struct.scsi_transport_iscsiallocates thescsi_host, and the initiator/iscsi_tcp.c's session structure is allocated in thathost_data.Yes, but
Kconfigisn't about lifetimes or, in fact, much of the way the code is constructed; it's about how the user selects particular features.
Quoted 6 lines
In the current setup, they have to know to say Y/M to the ISCSI attribute question even to see the config option for the iscsi initiator. This is a bit counter intuitive (and definitely isn't the way any of the other drivers that depend on transport classes are presented).
Yeah, sorry about that. With the userspace split and interpreting and implementing the review comments everything got a bit mixed up and we ended up the using the classes in a strange way. Should we resplit things up so that the host_alloc code is not part of the transport class? I think this will help the ql4xxx guys, Andrew have you started that?
Quoted 12 lines · Mike Christie
Quoted 10 lines · James Bottomley
Quoted 1 line · Mike Christie
I think the reason it was a dependency was becuase the transport class manages does the lifetime management/refcounting for the
initiators/iscsi_tcp.csession struct.scsi_transport_iscsiallocates thescsi_host, and the initiator/iscsi_tcp.c's session structure is allocated in thathost_data.Yes, but
Kconfigisn't about lifetimes or, in fact, much of the way the code is constructed; it's about how the user selects particular features.
Quoted 8 lines
Quoted 6 lines
In the current setup, they have to know to say Y/M to the ISCSI attribute question even to see the config option for the iscsi initiator. This is a bit counter intuitive (and definitely isn't the way any of the other drivers that depend on transport classes are presented).
Yeah, sorry about that. With the userspace split and interpreting and implementing the review comments everything got a bit mixed up and we ended up the using the classes in a strange way. Should we resplit things up so that the
host_alloccode is not part of the transport class? I think this will help the ql4xxx guys, Andrew have you started that?
And/or are there parts of the netlink interface you can use or will everything be done your fw/nvram? For example can you put part of the iSNS stuff in userspace then communicate through a modified iscsi netlink interface or is it not worth it or possible?