From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 8 17:50:37 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B404C16A4CE; Tue, 8 Feb 2005 17:50:37 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B011D43D46; Tue, 8 Feb 2005 17:50:36 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1CyZVQ-000668-Oi; Tue, 08 Feb 2005 19:50:32 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Scott Long In-Reply-To: Message from Scott Long of "Tue, 08 Feb 2005 10:25:44 MST." <4208F618.3000400@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Feb 2005 19:50:32 +0200 From: Danny Braniss Message-ID: cc: freebsd-scsi@freebsd.org Subject: Re: how CAM/HBA probe for devices? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2005 17:50:37 -0000 > 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