From: Jens Axboe <email@example.com>
To: Adam Manzanares <Adam.Manzanares@wdc.com>,
Christoph Hellwig <firstname.lastname@example.org>, Al Viro <viro@ZenIV.linux.org.uk>
Cc: kbuild test robot <email@example.com>,
Jeff Moyer <firstname.lastname@example.org>
Subject: Re: [vfs:work.aio 10/12] fs/aio.c:1444: undefined reference to `ioprio_check_cap'
Date: Fri, 1 Jun 2018 09:59:03 -0600 [thread overview]
Message-ID: <email@example.com> (raw)
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
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.
next prev parent reply other threads:[~2018-06-01 15:59 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
2018-06-01 15:59 ` Jens Axboe [this message]
2018-06-01 17:28 ` Matthew Wilcox
2018-06-01 20:31 ` Steve French
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).