LUN discovery by SCSI midlayer?

LUN discovery by SCSI midlayer?

[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

  (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

Re: LUN discovery by SCSI midlayer?

[Matt Domsch]

On Mon, Feb 14, 2005 at 08:35:25PM -0800, Joe Scsi wrote:
> 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.


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

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

Re: LUN discovery by SCSI midlayer?

[Joe Scsi]

> 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