From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 22:26:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F55816A4CE for ; Mon, 11 Oct 2004 22:26:29 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A6C143D39 for ; Mon, 11 Oct 2004 22:26:29 +0000 (GMT) (envelope-from scottl@FreeBSD.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i9BMQ1oR004086; Mon, 11 Oct 2004 16:26:01 -0600 (MDT) (envelope-from scottl@FreeBSD.org) Message-ID: <416B0852.9070605@FreeBSD.org> Date: Mon, 11 Oct 2004 16:25:22 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Jacob References: <20041011185906.38371.qmail@web21424.mail.yahoo.com> In-Reply-To: <20041011185906.38371.qmail@web21424.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@FreeBSD.org cc: Daniel Eriksson Subject: Re: Giant-free ahc? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 22:26:29 -0000 Matthew Jacob wrote: > No point in a giant-free SIM until CAM itself can cope. > > The isp driver has all the stuff in place to be Giant-Free, and might > even work, but there's no point if you have to transition in and out of > a Giant dependent subsystem. > > And the answer to the next question is: "No, I don't know who *really* > is working on a Giant-Free CAM". > I am, but I got sidetracked by these pesky release engineering tasks that people seem to care about =-) There is a branch called 'camlock' in perforce that has the beginnings of it. The big work so far in there has been to take the device probe out of the camisr context so that locking the rest of CAM is easier. Scott