Re: [RFC]: 64 bit LUN/Tags, dummy device in host_queue, host_lock <-> LLDD reentrancy

Mike Anderson
2002-08-26T20:57:20Z

James Bottomley [James.Bottomley@SteelEye.com] wrote:
> andmike@us.ibm.com said:
> > James I do not follow the usage of LUNs linked by pointers, can you
> > explain further?
>
> Yes: the mid-layer could function only with Scsi_Devices and Scsi_Hosts.
> LUNs are currently only used explicitly for scanning. However, I'd like to
> make the error handler handle the consequences of its action, thus it will
> need to know LUN relationships to handle a BDR correctly. However, the mid
> layer doesn't need an arbitrary number associated with LUN or PUN. Since the
> number, string or whatever is only really useful to the lld. So, simply put,
> we'd probably have an entry in the Scsi_Device for lun_list. This would be
> the usual doubly linked list so starting with any Scsi_Device we could always
> find the associated LUNs.
>

Ok, so we are looking for a sibling check. We should alter our driverfs
registration so that we pick this up for free by comparing the
de->parent of our scsi_device. Example tree shown below. Our scsi_device
devfs_entry would be pointing the lun leaf node. TBD on where all the
devfs_entrys get stored an who creates / destroys them.

Example tree
devices/root/pci0/00:09.0/name "PCI device 1014:002e"
devices/root/pci0/00:09.0/0/name "scsi0"
devices/root/pci0/00:09.0/0/0/name "chan0"
devices/root/pci0/00:09.0/0/0/1/name "tgt1"
devices/root/pci0/00:09.0/0/0/1/1/name "lun1"
devices/root/pci0/00:09.0/0/0/1/0/name "lun0"
devices/root/pci0/00:09.0/0/0/0/name "tgt0"
devices/root/pci0/00:09.0/0/0/0/1/name "lun1"
devices/root/pci0/00:09.0/0/0/0/0/name "lun0"

-Mike
--
Michael Anderson
andmike@us.ibm.com