On 06/13/2010 07:55 PM, FUJITA Tomonori wrote:
On Sun, 13 Jun 2010 15:10:39 -0500
Mike Christie<michaelc@xxxxxxxxxxx> wrote:
On 06/12/2010 05:37 PM, James Bottomley wrote:
On Fri, 2010-06-11 at 19:23 -0500, Mike Christie wrote:
On 06/11/2010 02:49 AM, Vikas Chaudhary wrote:
Added BSG support to enable application support to configure
ISP40XX/ISP82XX adapter.
This patch is on top of: http://marc.info/?l=linux-scsi&m=126999297630764&w=2
Did James say that using vendor specific commands was ok? I did not see
anything on the list.
In principle, the point about vendor specific host commands has already
been conceded ... lpfc and qla2xxx already use them.
I think the real rule is that for host specific BSG commands, it's only
for stuff that's specific to the host ... so not stuff which should be
done generically.
There are no hard and fast rules for applying the test above. In
theory, the management interfaces exposed by FC_BSG_HST_VENDOR could be
used to send commands ... but it tends to get tolerated as long as the
drivers support the standardised rport commands.
If I look at what the qla4xxx interface would do
1. it only supports vendor specific commands ... this is a bit of a
red flag since it's proposing to do nothing in a vendor neutral
way. This one, I punt back to you: what should an iscsi device
implementing BSG support of the standard commands
I am not 100% sure what we need yet, because qlogic has been pushing the
vendor specific route and I cannot see exactly what it needs with some
of its commands.
Based on other drivers and from looking at the qlogic tools and their
qlogic.com driver which seems to convert some management operations to
flash commands, I have the list below:
- Operation to set net settings like ip/dhcp, gateway, dns, subnet,
vlan, tcp/ip settings, speed/auto-negotiate, etc.
Besides supporting a IPv4 and IPv6 address, some cards can support lots
of IPs and/or vlans per same physical port, so this operation cannot be
tied to just the host.
- Operation to get port state.
- Operation to set iscsi initiator port settings like initiator
name/alias/isid, iscsi IO settings like FirstBurstLength or Digests,
auth settings like chap or radius, etc.
This should not be tied to the physical port either since we can have
multiple initiator ports per physical port.
- Operation to set iscsi settings for specific sessions like iSCSI IO
settings and auth settings mentioned above (some drivers want global
defaults settable at the host/initiator-port level then be able to
specify specific values for each session).
/sys/class/iscsi_* might work better for the above?
Yes and no. It works well when we just have to set 1 value, but if we
have to set multiple ones then we need to batch them up because it can
be disruptive to all sessions. When we set a setting in qla4xxx and
be2iscsi, then I think the card is basically not accessible while the
value is being set. So if we did use sysfs then we would need some other
files like maybe one to indicate that we are done setting params and the
card can write them to the flash now.
- Operation to discover targets and export targets that were found and:
- Operation to control if we want to log into specific targets that
were found.
- Operation to notify userpsace of network link state changes.
- Operation to notify userpsace of iscsi session/connection state changes.
bsg supports only the request/response interface. The event
notification from kernel space isn't fit for bsg.
Ah yeah, I just included it for completeness because in their previous
patchset they were using the scsi netlink code to add vendor specific
events for them.
Sounds like all the features are useful to any iSCSI HBAs?
Yeah, the iscsi ones are useful to any iscsi HBA that does
session/connection management in the card. The net ones are useful to
cards that do net management in the card.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
