--- Swen Schillig <swen@xxxxxxxxxxxx> wrote:
> I think Luben and Stefan suggested a good way to do that, ok apart from the be64 bits :-)
What is the objection to the use of be64_to_cpu()?
> So, just use the struct scsi_lun in its full extend, for the sysfs without a leading "0x",
> and forgetting about the scsilun_to_int conversion which isn't good for anything.
Yes, I agree with you. This is simple, straightforward, intuitive and reasonable.
In fact, I'd do
typedef __u8 lun_t[8];
and then define the macro
#define LUN_TO_U64(_lun) ((unsigned long long) be64_to_cpu(*(__be64 *)(_lun)))
This way one could do stuff like:*
printk(KERN_NOTICE "problem xyz with LUN:%016llx\n", LUN_TO_U64(sdev->LUN));
where
struct scsi_dev {
...
lun_t LUN; /* Or if you prefer all lowercase. */
...
};
And as can be seen in my SAS stack code:
kobject_set_name(&lu->lu_obj, "%016llx", LUN_TO_U64(lu->LUN));
(I actually don't have LUN_TO_U64() but reuse the SAS_ADDR() macro
which is identical.)
* It is in fact more correct to do, at the _transport_ layer:
printk(... "problem xyz with %016llx:%016llx\n",
sdev->target->tpid, sdev->LUN);
Here, it is explicitly shown that sdev (/dev/sdXYZ) is a child of
a target, having a tpid attribute, and the sdev has a property
of lun_t called LUN.
So, for example, for SAS, the message would print like this:
problem xyz with 5000a50000f13427:0000000000000000
which uniquely identifies the device and then the sysadmin
can go to the storage farm, find it and replace it if need be.
> Anyway, before anyone else is suggesting some other magic attribute extension to the LUN value,
> why not leave it as it is and just have it serving this one purpose of being a unique number ?
> (yeah, yeah I know there's already some meaning behind the 4 levels)
Again, you're exactly right. SCSI Core should NOT be interpreting the LUN.
It should just pass it around as an opaque token, as accomplished by the
lun_t type definition as shown above.
Luben
-
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
