On Monday, May 22, 2006 12:06 PM, Michael Reed wrote: > > > Changing mpt_config() to sleep changes the behavior in that > EAGAIN might no longer > be returned. lan, ctl, sas, spi, and fc all make use of > mpt_config(). This may be > non-trivial with regard to testing. Or it may not. And, as > James points out, > we have to assure that the caller is in a context which can sleep. > The caller context of mpt_config() *MUST* be able to sleep. Towards this end of this function we call wait_event(). This is because we are waiting on the firmware reply. If the fw reply doesn't come, then watchdog timer kicks in, then mpt_timer_expired is called. > Can we leave the interface alone for the moment and accept the patch > as written? Then, look at changing mpt_config() and the evaluate the > testing burden that the change might impose? > James? > My vested interest is in getting the functionality into certain > distros of interest. I have no problem with rearchitecting the > patchset as described above. I'm just concerned with the timing. > I suspect that the testing required will push the patch's acceptance > beyond my potential window of opportunity. As written, the change > is confined to fibre channel so will not potentially introduce > regressions into the other drivers. > How? I doubt there would be regressions. We would need to implement timeout on not receiving a mf, then return EAGAIN as we do today. Eric - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
