From owner-freebsd-scsi@FreeBSD.ORG Sat Jan 13 18:53:54 2007 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DC5116A403; Sat, 13 Jan 2007 18:53:54 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from ns1.scsiguy.com (mail.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 56B0A13C428; Sat, 13 Jan 2007 18:53:54 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from [70.89.174.89] (www.scsiguy.com [70.89.174.89]) by ns1.scsiguy.com (8.13.8/8.13.8) with ESMTP id l0DII5h0015549; Sat, 13 Jan 2007 11:18:05 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-ID: <45A9225D.4080907@scsiguy.com> Date: Sat, 13 Jan 2007 11:18:05 -0700 From: "Justin T. Gibbs" User-Agent: Thunderbird 1.5.0.8 (X11/20061214) MIME-Version: 1.0 To: mjacob@freebsd.org References: <20070104225519.Q92958@ns1.feral.com> <459E8AE7.90104@samsco.org> <20070105093930.Y34456@ns1.feral.com> <459E97E6.4000603@samsco.org> <459E989C.2020602@samsco.org> <20070105103431.A34456@ns1.feral.com> <20070105104021.D34456@ns1.feral.com> In-Reply-To: <20070105104021.D34456@ns1.feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: CAM rescanner thread? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2007 18:53:54 -0000 > Actually, no. Now that I think about it and look at the code in > cam_xpt.c, AC_FOUND_DEVICE seems to have a different semantic. It > seems to be an announcement to all periph's who care *after* the > device has been probed and configured. Yes. > If you look at xpt_async itself, it walks existing target and device > entries delivering the async_code. Even if the path for the async > event is a wildcard, it still needs a cam_ed to deliver something > to. There are wildcard cam_ed's in the tree that allow callbacks to be registered for events that happen at any level - even a fully wildcarded path. > The broadcast async stuff appears like it is *thinking* about having > this done. In fact, code in da (daasync) seems to want to do this- > but it requires initial inquiry data (via a ccb_getdev argument) > which really makes me scratch my head a bit. AC_FOUND_DEVICE should only be issued once the transport layer believes that a device is configured sufficiently to be used. > This is a prime example of how not having a mind-meld with Ken or > Justin really hurts. We can ask them what they were thinking about > this, and it'll probably make sense, but because this isn't all > very highly documented the architecture is often what you *guess* > it is :-). When the CAM code for FreeBSD was originally written, CAM3 was in development but not quite out yet. The draft documents contain some fledgling support for dynamic configuration and binding operations that dissassociate physical from logic addressing. You can still get CAM-3 here: http://www.t10.org/ftp/t10/drafts/cam3/cam3r03.pdf It's discovery and bind CCB types may be a good starting point for addressing these issues. With the discovery process moved to a thread and some augmentation to XPT_SCAN_*, we should be good enough for now. The only tricky part about using CCBs to intiate scanning is that they potentially require the allocation of memory from interrupt context. It would be nice to provide a service to all SIMs that can perform dynamic discovery such that they have a high probability of attaining their CCB in these situations. -- Justin