On Thu, 2013-02-21 at 16:15 +0000, Elliott, Robert (Server Storage) wrote: > Regarding changes like this: > - printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%d] " > + printk(MYIOC_s_NOTE_FMT "[%d:%d:%d:%llu] " > "FCP_ResponseInfo=%08xh\n", ioc->name, > sc->device->host->host_no, sc->device->channel, > sc->device->id, sc->device->lun, > > It might be preferable to print the LUN values in hex rather than > decimal, particularly if they are large values. SAM-5 includes some > guidance for displaying LUNs, shown below. We can't really change from decimal to hex without causing confusion and possibly breaking ABIs. All the existing SCSI references look like h:c:t:l and all expect l to be a simple decimal. It's not just in the logs, we have active use of this form in all the /sys/class/scsi_*/ directories and some tools may parse this value. > One important goal is to match the format, if any, that the user must > use in a configuration file or command line argument, so > cutting-and-pasting the LUN value works. So, the answer might differ > for prints from different drivers. If a driver expects decimal input > values, then print decimal. > > SAM-5 excerpt: > 4.7.2 Logical unit representation format [...] We're a bit bound by kernel convention here as well. To retain compatibility with SPI and flat addressing schemes, we really need to show the 8 and 16 bit flat addresses as simple decimal numerics. However, we *might* be free to move to a more hierarchical scheme with the multi-level luns, since I don't think there's to many people who've got arrays that output them (yet). James -- To unsubscribe from this list: 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
