On Fri, Mar 04, 2016 at 01:10:31PM -0500, Austin S. Hemmelgarn wrote:It wasn't intended as an argument for this continuing to be developed outside of blk-mq, but as an explanation of why the code exists as it does right now.
1. This all started long before blk-mq hit mainline.
Whoe cares? :)
For someone reading the code there might not be any ambiguity, but from the perspective of someone who isn't reading the code (or even someone who has limited background in kernel programming), it very much is ambiguous, especially what does and doesn't support I/O scheduling in general.2. There's still a decent amount of block drivers that don't support blk-mq.
Last time I looked (around the time 4.4 came out), I saw the following that
either obviously don't support it, or are ambiguous as to whether they
support it or not. Here's a list of just the ones I know are being used on
existing systems running relatively recent kernel versions, not including
There is no ambiguouity. You clearly named a few ones that aren't
converted, but also a lot of make_request_fn based drivers which don't
support any I/O scheduler.
But that whole point is that anything actively developed should moveAgreed.
over.