On 6/1/18 9:57 AM, Adam Manzanares wrote: > > > 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. It could, yes, but it isn't. As it stands, it's system call support to pass in IO priority for what ultimately is block storage. > 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? I don't think so. -- Jens Axboe
