Date: Fri, 5 Jan 2007 10:50:42 -0800 (PST) From: mjacob@freebsd.org To: Scott Long <scottl@samsco.org> Cc: freebsd-scsi@freebsd.org Subject: Re: CAM rescanner thread? Message-ID: <20070105104021.D34456@ns1.feral.com> In-Reply-To: <20070105103431.A34456@ns1.feral.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 5 Jan 2007, mjacob@freebsd.org wrote: > > >>> >>> Ok, I see what you're saying. What I think needs to ultimately happen is >>> for the entire probe code to go into a thread. I've tried this a >>> couple of times, but have been caught up in trying to separate out the >>> SPI and non-SPI bits of it. Your patch is looks to be a good start at >>> the more simple approach. >>> >>> Scott >>> >> >> Oh, one more thing. Instead of it being a new XPT API function, could it >> be an async op with an appropriate handler in the XPT? Heck, maybe >> this is exactly how you 'fix' AC_FOUND_DEVICE to DTRT. > > Yes. *blush*. You're right that this would be a better idea :-). Thanks. 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. 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. 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. 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 :-). -matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070105104021.D34456>