Skip to contentSkip to conversation

LUN discovery by SCSI midlayer?

DISCUSSION Joe Scsi 2 participants 3 messages Feb 15, 2005 SCSI

lore
Share & tools
lore

Joe Scsi

author
#0 lore raw

Hi,

I'm working on a driver for a SCSI protocol that is transported over a network. My basic plan is that when the driver is loaded, it will create a SCSI host structure
for its initiator port. Then target ports will be discovered asynchronously (and
may appear/disappear as target devices come and go on the network).

I'm wondering what the best way to handle LUN discovery is. Unfortunately it seems that scsi_add_device() can only add a single LUN at a time. However, for my protocol, I see target ports and then need to find the LUNs. So far I've come up with a couple of ideas but I'm not totally happy with either:

(ugly) Do all the REPORT_LUNs stuff in my driver every time I find a new target port, or

(ab)use the "channel" index and call scsi_scan_single_target() every time I connect to a new target port. This seems OK but I'm a little put off by the fact that a quick grep shows no callers of scsi_scan_single_target in the current kernel tree.

So what is the correct way to handle this? I'm sure the FC and iSCSI people must have dealt with a similar issue.

Thanks,
Joe

#1 lore raw
Quoted 17 lines · Joe Scsi

Hi,

I'm working on a driver for a SCSI protocol that is transported over a network. My basic plan is that when the driver is loaded, it will create a SCSI host structure
for its initiator port. Then target ports will be discovered asynchronously (and
may appear/disappear as target devices come and go on the network).

I'm wondering what the best way to handle LUN discovery is. Unfortunately it seems that scsi_add_device() can only add a single LUN at a time. However, for my protocol, I see target ports and then need to find the LUNs. So far I've come up with a couple of ideas but I'm not totally happy with either:

(ugly) Do all the REPORT_LUNs stuff in my driver every time I find a new target port, or

Quoted 7 lines

(ab)use the "channel" index and call scsi_scan_single_target() every time I connect to a new target port. This seems OK but I'm a little put off by the fact that a quick grep shows no callers of scsi_scan_single_target in the current kernel tree.

So what is the correct way to handle this? I'm sure the FC and iSCSI people must have dealt with a similar issue.

Can you take a look at the patches I posted last week and see if that would work for you?

http://marc.theaimsgroup.com/?l=linux-scsi&m=110780092314985&w=2

See then the megaraid_mbox.c driver patch in the thread for how it
converts logical drive numbers into HCTL values and invokes the hotplug subsystem. In your case, you'd use whatever your addressing mechanism is, and convert it into HCTL before invoking the hotplug calls.

Then you've got 2 options:
1) if you have a userspace app that knows when LUNs appear and disappear, then you write to /sys/class/scsi_host/hostN/lun_found (akin to logical_drive_created).

2) if your driver is what sees LUN arrivals/removals on the topology, then the driver just invokes the hotplug calls directly rather than expecting the event to originate via a sysfs file.

Thanks,
Matt

Signature · 4 lines
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
author
#2 lore raw
Quoted 2 lines

Can you take a look at the patches I posted last week and see if that would work for you?

Hmm, I'm not sure. The issue I have is that I know when target ports appear and disappear, and I'd like to use some general SCSI midlayer stuff to discover what LUNs are behind a target port. So if I have to know the full HCTL then that doesn't really help me.

It seems kind of ugly if I have to do the REPORT_LUNs command myself and manually call scsi_add_device() for each LUN.

(Disappearing target ports seem easier to handle, because I can keep a list of LUNs per target port and call scsi_remove_device() on each LUN)

Thanks,
Joe