From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f65.google.com ([209.85.214.65]:55989 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751687AbeFAP7H (ORCPT ); Fri, 1 Jun 2018 11:59:07 -0400 Received: by mail-it0-f65.google.com with SMTP id 144-v6so2380974iti.5 for ; Fri, 01 Jun 2018 08:59:06 -0700 (PDT) Subject: Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap' To: Adam Manzanares , Christoph Hellwig , Al Viro Cc: kbuild test robot , "kbuild-all@01.org" , "linux-fsdevel@vger.kernel.org" , Jeff Moyer References: <201806010845.bDzP7QCW%fengguang.wu@intel.com> <20180601005448.GN30522@ZenIV.linux.org.uk> <20180601051353.GA21589@lst.de> <9ad99d87-07c3-6611-3252-49d788f8028e@wdc.com> From: Jens Axboe Message-ID: <6f96a8de-143a-6b2c-fa89-72fed88b431e@kernel.dk> Date: Fri, 1 Jun 2018 09:59:03 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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