netdev - Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 27 Nov 2007 16:44:51 -0800
From:	"Anil Veerabhadrappa" <anilgv@...adcom.com>
To:	"Mike Christie" <michaelc@...wisc.edu>
cc:	"Mike Christie" <mchristi@...hat.com>,
	"Michael Chan" <mchan@...adcom.com>, davem@...emloft.net,
	netdev@...r.kernel.org, open-iscsi@...glegroups.com,
	talm@...adcom.com, lusinsky@...adcom.com, uri@...adcom.com,
	"SCSI Mailing List" <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH v3 2/2][BNX2]: Add iSCSI support to BNX2 devices.


> >> Which ones were they exactly? I think JamesB wanted only common 
> >> transport values in the transport class. If it is driver specific then 
> >> it should go on the host or target or device with the scsi_host_template 
> >> attrs.
> >>
> > 
> > It's a chicken & egg issue to put "port mapper" sysfs entry in scsi host
> > attributes. Application won't see sysfs unless initiator creates an
> 
> Sorry for the late response. I was on vacation.
> 
> That is only with how you coded it today. I asked you to do something 
> like qla4xxx where the session and host are not so closely bound.

bnx2i is still using scsi host per iscsi session model, we plan to
migrate to scsi host per device model pretty soon. Previously you
indicated that you are working on this port, can you please share the
code? We will build on your work and bring this to closure.


> 
> > iSCSI session and driver can't create an iSCSI session without a tcp
> 
> That is not right with how things are today even. The iscsi_session 
> struct can be created before the tcp connection. This was done because 
> we thought we were going to have to use only sysfs for all setup and 
> management (we ended up netlink and sysfs though).

You are right, software is flexible enough to allow creation of
session/connection and endpoint independently but so far user daemon
creates TCP endpoint before iSCSI session and bind them all together.
Any changes to this scheme will not be compatible with existing
distributions



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html