[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <17416A05-8401-4B03-B46C-78A8976C5B8E@linaro.org>
Date: Wed, 12 Apr 2017 08:01:44 +0200
From: Paolo Valente <paolo.valente@...aro.org>
To: Bart Van Assche <bart.vanassche@...disk.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"fchecconi@...il.com" <fchecconi@...il.com>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
"axboe@...nel.dk" <axboe@...nel.dk>,
Arianna Avanzini <avanzini.arianna@...il.com>,
"broonie@...nel.org" <broonie@...nel.org>,
"tj@...nel.org" <tj@...nel.org>,
"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>
Subject: Re: [PATCH V3 00/16] Introduce the BFQ I/O scheduler
> Il giorno 11 apr 2017, alle ore 20:31, Bart Van Assche <bart.vanassche@...disk.com> ha scritto:
>
> On Tue, 2017-04-11 at 19:37 +0200, Paolo Valente wrote:
>> Just pushed:
>> https://github.com/Algodev-github/bfq-mq/tree/add-bfq-mq-logical
>
> Thanks!
>
> But are you aware that the code on that branch doesn't build?
>
> $ make all
> [ ... ]
> ERROR: "bfq_mark_bfqq_busy" [block/bfq-wf2q.ko] undefined!
> ERROR: "bfqg_stats_update_dequeue" [block/bfq-wf2q.ko] undefined!
> [ ... ]
>
> $ PAGER= git grep bfq_mark_bfqq_busy
> block/bfq-wf2q.c: bfq_mark_bfqq_busy(bfqq);
>
That's exactly the complain of the kbuild test robot. As I wrote,
build completes with no problem in my test system (Ubuntu 16.04, gcc
5.4.0), even with the exact offending tree and .config that the robot
reports.
I didn't understand what is going on. In your case, as well as for
the test robot, the compilation of the file block/bfq-wf2q.c as a
module component fails, because that file does not contain the
definition of the reported functions. But that definition is
(uniquely) in the file block/bfq-iosched.c, which is to be compiled
with the former file, according to the following rule in
block/Makefile:
obj-$(CONFIG_IOSCHED_BFQ) += bfq-iosched.o bfq-wf2q.o bfq-cgroup.o
I have tried all combinations of configurations for bfq (builti-in or
module, with or without cgrousp support), always successfully. If it
makes any sense to share this information, these are the exact
commands I used to test al combinations (in addition to make full
builds in some cases, and try make all as in your case):
make O=builddir M=block
and
make O=builddir M=block modules
Where is my mistake?
Thanks,
Paolo
> Bart.
Powered by blists - more mailing lists