On Wed, 2007-01-31 at 12:44 -0700, Moore, Eric wrote: > On Wednesday, January 31, 2007 10:02 AM, James Bottomley wrote: > > This is wrong. the "int" represents our internal coding of the 8 byte > > extended LUN (currently it's a lossy transform that only allows up to > > two level LUNs, so one day this will definitely change). No driver > > should be using this internally. From the patches it merely > > looks like > > you want to print out the value of a struct scsilun in debugging code, > > so perhaps a simple print_scsilun or something would be better? > > > > James > > > No, this section of code is needed for more than printing the lun value. > Here is a snip from that patch you may of missed: > > - if ((mf->TargetID != ((u8)vdevice->vtarget->target_id)) || (mf->LUN[1] > != ((u8) vdevice->lun))) > +if ((mf->Bus != vdevice->vtarget->channel) || > + (mf->TargetID != vdevice->vtarget->id) || > + (lun != vdevice->lun))
Yes, I missed that. However, the mf (SCSIIORequest_t) comes back with the 8 byte luns, couldn't you just run vdevice->lun through int_to_scsilun and compare on that? I'm really reluctant to export the lun to int lossy transform because it will encourage bad uses. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
