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

Vikas Chaudhary
2010-06-16T02:43:44Z

>-----Original Message-----
>From: Mike Christie [mailto:michaelc@cs.wisc.edu]
>Sent: Sunday, June 13, 2010 1:11 PM
>To: James Bottomley
>Cc: Vikas Chaudhary; linux-scsi@vger.kernel.org; Ravi Anand
>Subject: Re: [PATCH 13/15] qla4xxx: Added bsg support
>
>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.

These operations are tied to per pci function in qla4xxx driver.

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

Here's the email thread info which outlines the initial patch we submitted
for link states changes : http://article.gmane.org/gmane.linux.scsi/58844

and based on Mike.C comment we are working on to make it more like FC where
it's based on LINK DOWN/UP etc rather than one generic AEN.

We are planning to resubmit the updated patch as part of our next patch set.