Re: SCSI Address

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Target and LUN are not part of CDB.

"Mike Fochtman" <MikeFochtman@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:882086C5-1FB5-4BCE-AD98-CD2C00EBBAE9@xxxxxxxxxxxxxxxx


"Maxim S. Shatskih" wrote:

xferpkt.c routines in classpnp. But the original version didn't seem
to
setup the LogicalUnitNumber member of the CDB.

I think this field is obsolete and now the selection of LUN is done using
some command which precedes the CDB flow.


Even if the field is 'obsolete' in WIndows, the SCSI specification for
SCSI
devices requires that the Command Device Block that is attached to all
SCSI
transfers on the bus must have the TargetID and Logical Unit Number
properly
embedded in them. I don't think it's a coincidence that the bit layout in
CDB6GENERIC and CDB10... and other CDB's in the WDK matches up with the
actual Command Device Block definitions in the SCSI-3 specification.

So somewhere between application and the SCSI HBA, *someone* has to make a
correlation between a particular device instance and the SCSI TargetID and
LUN of that device.

When the SCSI port first enumerates all the devices on the bus, it finds
eight instances of my device (because it responds to one TargetID with 8
different LUN's). My driver counts these and updates a
'nextAvailableNumber'
value in the registry under my key. So I know it's entered 8 times.

It also creates 8 unique DosDevice names that I can see from
QueryDosDevice() and use in CreateFile().

If it gets this far, and successfully opens, wouldn't that mean that each
instance is fully initialized and ready to go?

I can even do a WriteFile() to each, but the actual SCSI packet going
across
the wires on the SCSI bus has LUN of 0.

Sorry if my tone is too strong here, I apologize for that. Just that the
SCSI bus has to have a LUN (SCSI, SCSI-2 and SCSI-3 standards have all
required this). So it seems like it has to be associated with the PDO
*somewhere*.

Read the specs more. I think the current mechanism to distinguish across
LUNs is another, not the CDB field.


Another? If you mean 'another device instance', I agree. But regardless
of
what device instance, the packet being sent out the wire has to be
populated
correctly by some driver in the stack. If not mine, then where?

Mike



.

Relevant Pages

  • Re: SCSI Address
    ... LUN - was a part of the CDB in obsolete specs. ... Yes, you're both right about the TargetID, the Target is not in the CDB ... SCSI specs). ...
    (microsoft.public.development.device.drivers)
  • Re: SCSI Address
    ... I have to somehow find the appropriate LUN ... from the Irp so I can set that part of the CDB. ... So right now, all the SCSI ... "Maxim S. Shatskih" wrote: ...
    (microsoft.public.development.device.drivers)
  • Re: SCSI Address
    ... I have to somehow find the appropriate LUN ... from the Irp so I can set that part of the CDB. ... So right now, all the SCSI ... Each LUN will have its own driver installed. ...
    (microsoft.public.development.device.drivers)
  • Re: [PATCH repost 3] [SCSI] Retrieve the Caching mode page
    ... nor is designed to support ... So while REQUEST LUN /may/ work on some ... Those transport protocols define ... They also do not support SCSI Status completion of the ...
    (Linux-Kernel)
  • scsi emulation on two IDE devices
    ... both drives to use scsi emulation to copy from one drive to another. ... driver: ignore ...
    (linux.redhat.misc)