CAM rescanner thread?

[Scott Long]

mjacob at freebsd.org wrote:
> 
> 
> 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
> 

My next idea would be to just make it a CCB action then.  I'm trying to 
keep down the number of entry points so that it doesn't further 
complicate locking.  But we should also talk to Ken and Justin about it.

Scott