> -----Original Message----- > From: Christoph Hellwig [mailto:hch@xxxxxxxxxxxxx] > Sent: Saturday, March 31, 2007 2:27 AM > To: Ed Lin > Cc: linux-scsi; linux-kernel; james.Bottomley; jeff; Promise_Linux > Subject: Re: [PATCH 1/4] [SCSI]stex: fix id mapping issue > > > On Fri, Mar 30, 2007 at 03:21:33PM -0700, Ed Lin wrote: > > + if (hba->cardtype == st_shasta) { > > req->lun = lun; > > req->target = id; > > + } else if (hba->cardtype == st_yosemite){ > > + req->lun = id * ST_MAX_LUN_PER_TARGET + lun; > > + req->target = 0; > > + } else { > > + /* st_vsc and st_vsc1 */ > > + req->lun = 0; > > + req->target = id * ST_MAX_LUN_PER_TARGET + lun; > > I don't get why you can't export id as targer and lun as lun for > the !st_shasta types. Could you explain in detail what the problem > with that approach would be? > > Of course I can do that. That will result in 1 target and 128 lun for st_yosemite and 128 target and 1 lun for st_vsc. That seems a little weird and I am afraid it will be turned down. Also I can keep a same mapping for the console in the original code. If you think it's ok, that's really better, because it makes the hot path a bit faster. Also because of the CONFIG_SCSI_MULTI_LUN option, I have to map lun to channel otherwise many entities will disappear when that option is not selected. Plus I have to reserve a slot for the RAID console, so the final mapping may be: channel:0~7, id:0~16(st_shasta, channel 0,id 16 is reserved for console) channel:0~127, id:0~1(st_yosemite, channel 0,id 1 is reserved for console) channel:0, id:0~128(st_vsc, channel 0,id 128 is reserved for console) I don't know whether this is acceptable. - 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
