how CAM/HBA probe for devices?

[Danny Braniss]

> 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.
> 
i was thinking in tricking the CAM layer in thinking that the iSCSI
is a HBA, with only one bus/target, at least till i can understand
the protocol, then it will be time to see how many session/targets
can be realized.

> 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 got the lucent driver, if that's what you mean by digging up ...

> 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.
> 
sure!

> 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.

im not scared, just can't see the wood because of the trees :-)
i mean, trying to write a klm/iSCSI/CAM/SCSI/TCP-IP driver is fun, but
can't expect to know SAM-n, sockets, threads/mutex/etc, etc.

i'm trying to work with what there is, and in the way try to learn how iSCSI
works. in doing so, trying to design the software.

the next thing i need, and im looking now at the atapi-cam, is to figure out
how i can tye my loose ends.

> 
> Scott