On Fri, 2009-06-12 at 08:08 -0700, Grant Grundler wrote:
> >> + list_for_each_entry(temp, &pinstance->used_res_q, queue) {
> >> +
> >> + /* do not expose VSETs with order-ids >= 240 */
> >> + if (RES_IS_VSET(temp->cfg_entry)) {
> >> + target = temp->cfg_entry.unique_flags1;
> >> + if (target >= PMCRAID_MAX_VSET_TARGETS)
> >> + continue;
> >> + bus = PMCRAID_VSET_BUS_ID;
> >> + lun = 0;
> >> + } else if (RES_IS_GSCSI(temp->cfg_entry)) {
> >> + target = RES_TARGET(temp->cfg_entry.resource_address);
> >> + bus = PMCRAID_PHYS_BUS_ID;
> >> + lun = RES_LUN(temp->cfg_entry.resource_address);
> >
> > I assume this means this adapter only supports single byte LUNs...
>
> ISTR, SCSI-3 spec only defines 5-bits for the LUN field...but my SCSI-foo
> pretty old and I might misremember. It was easy to find this reference:
> http://en.wikipedia.org/wiki/SCSI_Read_Commands
>
> I'm sure there something better from t10.org but everything requires
> a login now and I'm sure someone here will just know this.
Actually, no, that was SCSI-2, and even there we used transport updates
to go beyond 32 LUNs.
SCSI-3 defines lun hierarchies up to 8 bytes long. Identifying the LUN
when you send a command is now the job of the transport.
What brian means is the definition of the lun variable is only 8 bytes
long:
> + u8 target, bus, lun;
However, if you look at the RES_LUN() definition, it doesn't actually
support any LUNs at all:
> +#define RES_LUN(res_addr) 0x0
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
