On 10/23/05 12:49, Jeff Garzik wrote: > Stefan Richter wrote: > >>I wrote: >> >> >>> for (i = 0; i < 8; ++i) >>> sprintf(s+2*i, %02x, lun[i]); >> >> sprintf(s+2*i, "%02x", lun.scsi_lun[i]); >>#-) > > > > There is obviously room for improvement. Any naive representation is > sub-optimal, be it for small luns (my current code) or larger luns (your > example). > > For situations with smaller luns, we should probably continue to use the > current scsilun_to_int() conversion, while using your example for larger > luns, i.e. > > if (upper 4 bytes zero) > scsilun to int > printk %d > else > for each byte > printk %x > > But Douglas's code suggested that if we are more motivated, we could > provide an even better representation. If a LUN is u8[8], then, #define SAS_ADDR(_sa) ((unsigned long long) be64_to_cpu(*(__be64 *)(_sa))) "%016llx", SAS_ADDR(LUN) prints it like this (e.g.): sas: 5000c50000513329 probing LUN:0000000000000000 sas: device 500000e000031c12 LUN: 0000000000000000 powering up or not ready yet, sleeping... sas: 500000e000031c12 probing LUN:0000000000000000 sas: device 50001c171601060d LUN: 0000000000000000 powering up or not ready yet, sleeping... This is from drivers/scsi/sas/sas_discover.c. 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
