On 6/1/18 8:41 AM, Jens Axboe wrote: > On 6/1/18 9:38 AM, Adam Manzanares wrote: >> On 5/31/18 10:13 PM, Christoph Hellwig wrote: >>>> +extern int ioprio_check_cap(int ioprio); >>> >>> Which then is implemented in block/ioprio.c, which depends on >>> CONFIG_BLOCK. The code either needs a stub for !CONFIG_BLOCK >>> or moved elsewhere. >> >> My vote would be to move the ioprio code into fs/. At first glance I do >> not see a dependence on the block layer in block/ioprio.c. >> >> Any objections? > > Since it's block ioprio code, I'd prefer a stub instead. > This feature could be used independently from the block layer. We have examples (ATA, hopefully NVME soon) where we are reacting to the ioprio in the device drivers essentially passing the ioprio through the block layer. Although I am currently unaware of a concrete example of a device that is not using a block layer based driver and has support for IO determinism, do you think there is any value in moving all of the block ioprio code out of the block layer?
