Date: Tue, 08 Feb 2005 19:50:32 +0200 From: Danny Braniss <danny@cs.huji.ac.il> To: Scott Long <scottl@freebsd.org> Cc: freebsd-scsi@freebsd.org Subject: Re: how CAM/HBA probe for devices? Message-ID: <E1CyZVQ-000668-Oi@cs1.cs.huji.ac.il> In-Reply-To: Message from Scott Long <scottl@freebsd.org> of "Tue, 08 Feb 2005 10:25:44 MST." <4208F618.3000400@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1CyZVQ-000668-Oi>