Re: Pack of CAM improvements

Scott Long wrote:
> On Jan 19, 2010, at 9:12 AM, Alexander Motin wrote:
>> I've made a patch, that should solve set of problems of CAM ATA and CAM
>> generally. I would like to ask for testing and feedback.
>>
>> What patch does:
>> - It unifies bus reset/probe sequence. Whenever bus attached at boot or
>> later, CAM will automatically reset and scan it. It allows to remove
>> duplicate code from many drivers.
>> - Any bus, attached before CAM completed it's boot-time initialization,
>> will equally join to the process, delaying boot if needed.
>> - New kern.cam.boot_delay loader tunable should help controllers that
>> are still unable to register their buses in time (such as slow USB/
>> PCCard/ CardBus devices).
> 
> I've fought many times against delay values like this.  They never work
> well enough.  Drivers that have delayed scans should set up their own
> intrhook to delay the boot until their scan is done.  To help this out,
> CAM should move to its own hook that is guaranteed to run after the
> normal intrhooks.  However, this isn't required.

I am sure that using delay is not a perfect solution, but it nicely fits
new scanning procedure and costs just a few lines of code. Nobody denies
to add _more_ events to wait there. This is just a band-aid for cases
when nothing else helps. May be I am mixing something, but AFAIR there
were some USB devices, which doesn't appear on a first bus scan, but
register later.

> Here's my alternate proposal:
> 
> - move xpt_config() execution to a new config hook that runs after the
> normal intrhooks.

To make scanning work in background, it is better to call xpt_config()
same as now, as early as possible, to start scanning for already
registered buses, but call xpt_release_boot() on some later event (or
even several different events).

> - For self identifying buses (i.e. anything where device presence is
> known to the controller), have the SIM notify CAM of each target device,
> instead of assuming that CAM will scan for it.

Nobody denies your driver to call xpt_rescan on per-known-device basis.
In such case CAM will still wait until all of your scan requests will be
fulfilled. You may see it is already done by some SIMs and PMP driver.
If you need a way to avoid full scan, it also can be done, while it is
separate question.

> - Teach USB and whatnot to use a confighook to drive their discovery,
> instead of estimated timeouts.
> 
> I'm doing exactly this for the new MPT2SAS driver.

-- 
Alexander Motin