31f639ecdf
at insert time. When asking gibbs for approval for an MFC, this was his reply: 1) It leaks memory if it can't allocate a path. 2) It defers allocation of aic->path until the call to scan the bus. This means the path may be NULL when an interrupt occurs prior to the call to scan the bus (stray bus reset for instance), which will lead to a panic. 3) The driver in current doesn't recover from the failure to allocate aic->path. The driver doesn't check during normal operation if the path is NULL, so again a panic will result. 4) aic_cam_rescan calls malloc with M_WAITOK. aic_cam_rescan is called from attach where it isn't necessarily safe to sleep. 5) And most importantly, it co-opts the xpt_periph from the driver level. This was never part of the design (xpt_periph used to be static). Making a call of this type may completely confuse the XPT if other XPT operations are ongoing. In the long term, Justin and Warner agreed to implement solution where CAM itself will initiate the bus rescan if a new bus is added. For the time being (and in particular in light of the upcoming 4.5 release), we now have camcontrol available on the boot floppy, and can have pccardd initiate the rescan through it. |
||
|---|---|---|
| .. | ||
| aic6360reg.h | ||
| aic_cbus.c | ||
| aic_isa.c | ||
| aic_pccard.c | ||
| aic.c | ||
| aicvar.h | ||