how CAM/HBA probe for devices?

Scott Long scottl at freebsd.org
Tue Feb 8 09:25:53 PST 2005


Danny Braniss wrote:

> i have been writing a driver for the iSCSI, and am concentrating
> on the initiator side.
> So far i mannaged to get to first base, ie, managed to login onto a target,
> but now im stuck.
> After several hours of reading/searching, this is avoiding me:
> 	how can i get the CAM to probe for devices on this 'controller'?
> thanks,
> 	danny
> 

A scan is performed when CAM gets an XPT_SCAN_BUS command.  This happens
automatically during boot after the XPT_RESET_BUS command finishes.  A 
driver or userland app can send an XPT_SCAN_BUS command at any time via 
various interfaces.

However, you've just hit the first big blocker in iSCSI support.  CAM is 
oriented around parallel SCSI, and in parallel SCSI you do a linear scan 
of targets from 0 to 7 or 15, depending on the bus width.  LUNs are also 
scanned linearly on each target, though we need to implement the 
REPORT_LUNS feature so that we can efficiently detect high LUNs without 
needing a linear scan.  Anyways, the linear scan of targets works 
because the range is very small and bounded.

For iSCSI, this obviously won't work.  CAM has no concept of iSCSI 
addresses, and even if it did, doing a linear scan of even a small 
subnet would be prohibitively expensive.  What is really needed is a new 
XPT layer that understands iSCSI.  By this, I mean a layer that 
understands how to properly scan and detect targets, how to log into
them, etc.  It should also have a certain amount of flexibility so that 
hardware-assisted solutions can plug in and pick-and-choose the pieces 
they need from the transport layer.

Lucent did an iSCSI initiator for FreeBSD 4.x a while back and I think
they got around all of this by telling CAM not to auto-scan at boot,
followed by having the driver announce devices to CAM directly (look at
the ATAPI-CAM code for an example of how to do this) and do all the
detection and login work behind CAM's back.  This really should only be
considered a hack though.  If you're interested, I might be able to dig
up the link to it.  We never pursued integrating it to the FreeBSD tree
because of very restrictive licensing terms on it.

I started some preliminary work last spring on cleaning up CAM to 
segregate parallel SCSI knowledge into its own module.  This should 
eventually allow a system where multiple XPT modules can live together 
and each provide a different transport.  At the end, I'd like to see 
transports for p-scsi, iscsi, sas, ata/sata, and fc.  This is of course 
in my fantasy world of inifinite hacking time =-)  If you're interested 
in helping, I'd love to talk to you some more offline.

Please don't let this scare you away from what you're doing.  iSCSI
support is badly needed, and I'm thrilled that your working on it.  If
there is anything I can do to help, please ask.

Scott


More information about the freebsd-scsi mailing list