CAM rescanner thread?

[mjacob at freebsd.org]

On Fri, 5 Jan 2007, mjacob at 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