From: Adam Manzanares <Adam.Manzanares@wdc.com>
To: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Al Viro <viro@ZenIV.linux.org.uk>
Cc: kbuild test robot <lkp@intel.com>,
"kbuild-all@01.org" <kbuild-all@01.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Jeff Moyer <jmoyer@redhat.com>
Subject: Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
Date: Fri, 1 Jun 2018 15:57:48 +0000 [thread overview]
Message-ID: <edac24e9-5562-faf9-c5a6-dce8e832eefe@wdc.com> (raw)
In-Reply-To: <f24fe7e0-8531-bdca-4571-9a8caa4b4e70@kernel.dk>
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?
next prev parent reply other threads:[~2018-06-01 15:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 0:36 [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap' kbuild test robot
2018-06-01 0:54 ` Al Viro
2018-06-01 1:02 ` Al Viro
2018-06-01 1:12 ` [kbuild-all] " Li, Philip
2018-06-01 5:13 ` Christoph Hellwig
2018-06-01 15:38 ` Adam Manzanares
2018-06-01 15:41 ` Jens Axboe
2018-06-01 15:57 ` Adam Manzanares [this message]
2018-06-01 15:59 ` Jens Axboe
2018-06-01 17:28 ` Matthew Wilcox
2018-06-01 20:31 ` Steve French
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edac24e9-5562-faf9-c5a6-dce8e832eefe@wdc.com \
--to=adam.manzanares@wdc.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=jmoyer@redhat.com \
--cc=kbuild-all@01.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).