From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 8 22:10:13 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 EB3E016A4D0 for ; Tue, 8 Feb 2005 22:10:13 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 700A943D41 for ; Tue, 8 Feb 2005 22:10:13 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j18MAU8i005668; Tue, 8 Feb 2005 15:10:31 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <420938BC.6050800@freebsd.org> Date: Tue, 08 Feb 2005 15:10:04 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Nelson References: <4208F618.3000400@freebsd.org> <20050208214956.GA3104@dan.emsphone.com> In-Reply-To: <20050208214956.GA3104@dan.emsphone.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org 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 22:10:14 -0000 Dan Nelson wrote: > In the last episode (Feb 08), Scott Long said: > >>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. > > > The fibre-channel drivers (isp,mpt) must have been the first to have > hit this problem; do they do the same thing as atapicam? > Well, FC support in CAM is really limited to only simple arbitrated loops. Unless the driver and/or firmware gets involved and massages CAM's view of things, trying to do active-active loops and fabrics just isn't possible. Scott