On 10/24/18 6:02 AM, Jens Axboe wrote: > On 10/24/18 5:52 AM, Jens Axboe wrote: >> On 10/24/18 5:30 AM, Jens Axboe wrote: >>> On 10/24/18 5:19 AM, Christoph Hellwig wrote: >>>> On Mon, Oct 22, 2018 at 03:23:30AM -0600, Jens Axboe wrote: >>>>> JFYI, I also reordered the series to make it correct. You can apply >>>>> this one: >>>>> >>>>> http://git.kernel.dk/cgit/linux-block/commit/?h=mq-conversions&id=2b2ffa16193e9a69a076595ed64429b8cc9b42aa >>>>> >>>>> before the bsg patch, and it should be fine. Or just use the above branch, >>>>> of course. >>>> >>>> Hell no on that one. The behavior of having methods right on the >>>> request_queue which can be changed any time is something we absolutely >>>> must not introduce into blk-mq. >>> >>> I agree it's not the prettiest, but it's not like it's something >>> that is changed at runtime. >>> >>>> Just add pass a timeout hander to bsg_register_queue which is called >>>> from the bsg ->timeout handler is a much better way to sort our your >>>> problem. It can also easily be turned into an independent prep patch. >>> >>> Good idea, that is cleaner. >> >> Except that STILL doesn't work with mq_ops being a constant, I'd have >> to allocate it. > > Which obviously won't work. I don't see a good way out of this, since > I can't store the private timeout handler anywhere. Open to suggestions, > but until something better comes up, I'm keeping q->timeout and > removing the API to set it. bsg-lib can just manually set it in the > queue. Pushed that out - it's now ->bsg_job_timeout_fn, and nobody sets it but bsg when it initializes the queue. bsg sets up a default timeout handler, and calls ->bsg_job_timeout_fn, if defined. Not that that is any different than from before, but at least it's obvious what it's for now. -- Jens Axboe
