Re: [PATCH 2.6.13 5/14] sas-class: sas_discover.c Discover process (end devices)

Luben Tuikov
2005-09-14T17:17:49Z

On 09/14/05 13:13, Patrick Mansfield wrote:
> On Wed, Sep 14, 2005 at 08:28:29AM -0400, Luben Tuikov wrote:
>
>>On 09/13/05 18:42, Patrick Mansfield wrote:
>
>
>>>What I mean is that the target has to intercept the command whether it is
>>>a REPORT LUN or for the well known (W_LUN).
>>>
>>>The target (firmware) code has to have code today like:
>>>
>>> if (cmd == REPORT_LUN) {
>>> do_report_lun();
>>> }
>>>
>>>For only W_LUN support, the code might be something like:
>>>
>>> if (lun == W_LUN) {
>>> if (cmd == REPORT_LUN) {
>>> do_report_lun();
>>> }
>>> }
>>>
>>>But the first case above already covers even the W_LUN case.
>>
>>_Except_, that what the firmware actually does is, it routes
>>the tasks by LUN first, _before_ looking up with what the command
>>is.* This is crucial.
>
>
> That is what the second code snippet above is meant to show.

It was completely unclear what you meant since your code was
scattered in English text and you did not mention that
firmware does LU routing first, to quote:
"The target (firmware) code has to have code today like:"

>>>So adding a W_LUN at this point does not add any value ... maybe it looks
>>>nice in the spec and in someones firmware, but it does not add anything
>>>that I can see.
>>
>>I wonder if the maintainer of the SCSI Core would listen or ignore your
>>opinion here.
>
>
>>I wonder _who_ decides here where speculation ends and industry
>>opinion starts?
>
>
> I am talking about the scsi spec, not the code. IMO linux scsi code should
> support W_LUN and 64 bit LUN.

Ok, that's good.

Luben