On Fri, Jun 01, 2018 at 09:59:03AM -0600, Jens Axboe wrote: > 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. I think it'd be interesting if NFS/SMB decided to start using it. I think SMB has the concept of io priorities within a single stream ... Steve? -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
