On Wed, Feb 5, 2014 at 1:22 AM, David Laight <David.Laight@xxxxxxxxxx> wrote: > From: Dan Williams >> > Adding another list that will have its own set of bugs seems retrograde top me. >> >> What bugs? Please be specific. The problem to be addressed is not >> the allocation of commands, but that timeouts of one command eat the >> timeout periods of subsequent commands. I'm thinking a >> single-threaded workqueue better models what the hardware is doing. >> See my comments in patch 1, but that is orthogonal to how the command >> contexts are allocated. > > No software is bug free. > The best way to get reasonably bug-free software is the KISS principle > (Keep It Simple Stupid). I find this condescending. Perhaps you did not mean for it to come out that way, but this is far from a specific technical argument. > You just seem to be adding a lot of additional complexity. > Maybe it would look better if more of the code was factored out of the > call sites. > > IIRC at the moment every call site has to: > 1) find the trb address that will be used (massive layer break). > 2) actually write the trb (through several layers of function call). > 3) sort out any timeout (I didn't really look into this bit). > 4) ring the bell. I think there is room to push these pre-requisites down. > ISTM that the call site should just be a single function call. > If you do that the implementation of the timeouts/completions is > removed from the callers. Yes, but I think we need to centralize the context under which commands are submitted. The complicating factor is the mix of synchronous command submission and interrupt driven asynchronous command queuing. I think we can simplify it by making it all submitted from a single event queue context. I'm investigating if that is a workable solution... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
