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