Re: [PATCH 13/15] qla4xxx: Added bsg support

[Mike Christie <michaelc@cs.wisc.edu>]

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

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