On Oct 24, 2005, at 3:03 PM, Stefan Richter wrote:
Luben Tuikov wrote:
On 10/23/05 12:49, Jeff Garzik wrote:
Stefan Richter wrote:
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.
A plain, non-interpreted representation should suffice. Compact but
easily parseable, i.e. uniform.
If a LUN is u8[8], then,
#define SAS_ADDR(_sa) ((unsigned long long) be64_to_cpu(*(__be64
*)(_sa)))
This could be a problem because if a LUN is u8[8], it may not be
aligned, so casting to __be64 and such could be a problem in some
architectures.
"%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
What about an 64bit integer as carrier of LUN in the first place? The
most frequent occurrence of LUN data is when it is passed through in
function calls but it seems rarely to be manipulated.
--- linux/include/scsi/scsi.h.orig 2005-10-20
08:23:05.000000000 +0200
+++ linux/include/scsi/scsi.h 2005-10-24 21:45:41.000000000 +0200
@@ -238,9 +238,7 @@
/*
* ScsiLun: 8 byte LUN.
*/
-struct scsi_lun {
- __u8 scsi_lun[8];
-};
+typedef __be64 scsi_lun;
/*
* MESSAGE CODES
Typedef-ing to __be64 would seem to avoid the likely alignment
problem that the casting solution above could run into. I have to say
that I don't know enough about SCSI to make a recommendation, but I
know enough about alignment problems in some architectures to worry
about that.
--
Mark Rustad, MRustad@xxxxxxx
-
: 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
