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

[Patrick Mansfield <patmans@us.ibm.com>]

On Wed, Sep 14, 2005 at 01:22:46AM -0400, Sergey Panov wrote:
> On Tue, 2005-09-13 at 15:25 -0700, Patrick Mansfield wrote:

> > Not all HBA drivers implement a mapping to a SCSI transport, we have
> > raid drivers and even an FC driver that has its own lun definition that
> > does not fit any SAM or SCSI spec.
> 
> May I ask you to name those drivers/HBAs, it would be interesting to
> look at how REPORT_LUN results are interpreted there. Actually, the data
> from the  REPORT_LUN response is always treated as proper  8 byte LUN
> and it is converted to int by scsilun_to_int(). What is interesting is
> how those derivers/HBA treat integer "lun" in queuecommand or EH calls.

I didn't look at raid driver code, I mean they can setup and use luns
however they want, as they are not following any scsi transport specs.

In drivers/scsi/qla2xxx/qla_iocb.c qla2x00_start_scsi(), it is swapped as
firmware wants le, and then the firmware has to convert it to a proper 8
byte LUN:

	cmd_pkt->lun = cpu_to_le16(sp->cmd->device->lun);

(I'm not sure where or how they handle 8 byte LUN for qla24xx per Ravin's
email).

> > So, we can't have one "LUN" that fits all, and it makes no sense to call
> > it a LUN when it is really a wtf.
> 
> IMHO one 8 byte LUN is better then wtf. I's kinda obvious :)

Yes :)

-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/