On 10/23/05 01:22, Douglas Gilbert wrote:
>>A further experiment: once dev_printk() has been used to eliminate
>>direct references to HCIL address (see previous patch), we can see what
>>happens when we update the core to use struct scsi_lun.
>>
>>DO NOT APPLY.
>>
>>Depends on previous "kill scsi_device::{channel,id} in generic code"
>>patch.
>>
>>Changes:
>>
>>* replace 'unsigned int lun' with 'struct scsi_lun lun' in struct scsi_device
>>
>>* change various function args to receive 'const struct scsi_lun *'
>> rather than unsigned int.
>>
>>* export scsilun_to_int()
>>
>>* create scsilun_to_str() helper
>>
>>* create scsilun_eq() helper
>>
>>* update all references to scsi_device::lun, as caught by the compiler.
>>
>> Again, generic code was 100% converted, driver code 0% converted.
>>
>>* int_to_scsilun() is used to convert SCSI-2 luns, and luns passed
>> from userspace as integers, to struct scsi_lun.
>>
>>* shost->max_lun check moved into scsi_scan_host_selected() callers
>
>
> Jeff,
> With 8 byte luns, max_lun is legacy. I found it a nuisance
I agree.
Furthermore, a LUN is just u8[8] and I don't think there's a reason
to wrap that in a struct. (Incidentally a logical unit number is
not a number but a structure.)
Other than application clients and device servers, I don't think
that the kernel should in anyway interpret the LUN structure.
It is just u8[8] and this is what the kernel should pass around.
Cf. drivers/scsi/sas/sas_discover.c and include/scsi/sas/sas_task.h.
Luben
--
http://linux.adaptec.com/sas/
http://www.adaptec.com/sas/
-
: 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
