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