[PATCH] move iscsi to a better place in Kconfig

[PATCH] move iscsi to a better place in Kconfig

[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.

James

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -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

Re: [PATCH] move iscsi to a better place in Kconfig

[Mike Christie]

James Bottomley wrote:
> 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.


> 
> James
> 
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] move iscsi to a better place in Kconfig

[James Bottomley]

On Thu, 2005-09-08 at 14:23 -0500, Mike Christie wrote:
> 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.

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

Re: [PATCH] move iscsi to a better place in Kconfig

[Mike Christie]

James Bottomley wrote:
> On Thu, 2005-09-08 at 14:23 -0500, Mike Christie wrote:
> 
>>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.
> 
> 
> 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).
> 

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?

Re: [PATCH] move iscsi to a better place in Kconfig

[Mike Christie]

Mike Christie wrote:
> James Bottomley wrote:
> 
>> On Thu, 2005-09-08 at 14:23 -0500, Mike Christie wrote:
>>
>>> 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.
>>
>>
>>
>> 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).
>>
> 
> 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?

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?