From: Fengguang Wu <fengguang.wu@intel.com>
To: Yilong Ren <yilongx.ren@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Johannes Thumshirn <jthumshirn@suse.de>,
kbuild-all@01.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [kbuild-all] make[2]: *** No rule to make target 'tools/testing/nvdimm//config_check.o', needed by 'tools/testing/nvdimm//dax.o'.
Date: Tue, 16 Aug 2016 09:58:43 +0800 [thread overview]
Message-ID: <20160816015843.GA12894@wfg-t540p.sh.intel.com> (raw)
In-Reply-To: <20160816014751.GC6835@localhost.localdomain>
On Tue, Aug 16, 2016 at 09:47:52AM +0800, Yilong Ren wrote:
>On Tue, Aug 16, 2016 at 09:41:02AM +0800, Fengguang Wu wrote:
>> On Mon, Aug 15, 2016 at 06:30:48PM -0700, Dan Williams wrote:
>> >On Mon, Aug 15, 2016 at 6:26 PM, Fengguang Wu <fengguang.wu@intel.com> wrote:
>> >>On Mon, Aug 15, 2016 at 05:58:36PM -0700, Dan Williams wrote:
>> >>>
>> >>>On Mon, Aug 15, 2016 at 3:03 AM, kbuild test robot
>> >>><fengguang.wu@intel.com> wrote:
>> >>>>
>> >>>>tree:
>> >>>>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> >>>>head: 694d0d0bb2030d2e36df73e2d23d5770511dbc8d
>> >>>>commit: ab68f26221366f92611650e8470e6a926801c7d4 /dev/dax, pmem: direct
>> >>>>access to persistent memory
>> >>>>date: 3 months ago
>> >>>>config: i386-randconfig-i1-201633 (attached as .config)
>> >>>>compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
>> >>>>reproduce:
>> >>>> git checkout ab68f26221366f92611650e8470e6a926801c7d4
>> >>>> # save the attached .config to linux build tree
>> >>>> make ARCH=i386
>> >>>>
>> >>>>All errors (new ones prefixed by >>):
>> >>>>
>> >>>>>>make[2]: *** No rule to make target
>> >>>>>>'tools/testing/nvdimm//config_check.o', needed by
>> >>>>>>'tools/testing/nvdimm//dax.o'.
>> >>>>
>> >>>> make[2]: Target '__build' not remade because of errors.
>> >>>
>> >>>
>> >>>I think this is an invalid build test. tools/testing/nvdimm/ uses a
>> >>>external module Kbuild environment, not Kconfig. So, there's nothing
>> >>>I can do to prevent this compile error, unless there's some other way
>> >>>0-day could determine the configuration dependencies?
>> >>
>> >>
>> >>Yeah if you can offer a concrete rule for the dependency, we'll add
>> >>it to 0-day.
>> >
>> >Sounds good. The config_check.c file itself lists the dependencies:
>> >
>> >void check(void)
>> >{
>> > /*
>> > * These kconfig symbols must be set to "m" for nfit_test to
>>
>> If "y" is not a valid option, we'll need to adjust 0-day's dependency
>> specification for ndctl test:
>>
>> wfg /c/lkp-tests% cat include/ndctl
>> need_kconfig:
>> - CONFIG_HAVE_DMA_CONTIGUOUS=y
>> - CONFIG_CMA=y
>> - CONFIG_DMA_CMA=y
>> - CONFIG_CMA_SIZE_MBYTES=200
>> - CONFIG_LIBNVDIMM
>> - CONFIG_BLK_DEV_PMEM
>> - CONFIG_ND_BLK
>> - CONFIG_BTT=y
>> - CONFIG_NVDIMM_PFN=y
>> - CONFIG_NVDIMM_DAX=y
>> - CONFIG_ZONE_DEVICE=y
>>
>> In the above list, a bare "CONFIG_BLK_DEV_PMEM" means "y" or "m" are
>> both acceptable.
>
>Yes, this is due to enable_module() can accept "y" and "m".
>How about forcing enable_module() to accept "m" ?
I think we could change
- CONFIG_BLK_DEV_PMEM
to
- CONFIG_BLK_DEV_PMEM=m
The former will correspond to kernel's
#define IS_ENABLED(option) __or(IS_BUILTIN(option), IS_MODULE(option))
while the latter correspond to
#define IS_MODULE(option) config_enabled(option##_MODULE)
And add logic to handle the =m case. Currently we only have
enable_module() which corresponds to kernel's IS_ENABLED().
> 23 # CONFIG_XXX=m => unchange
> 24 # CONFIG_XXX=y => unchange
> 25 # CONFIG_XXX is not set => CONFIG_XXX=m
> 26 enable_module()
The behavior here is good for its current callers, except the "module"
in the function name might be a bit misleading.
Thanks,
Fengguang
next prev parent reply other threads:[~2016-08-16 1:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-15 10:03 make[2]: *** No rule to make target 'tools/testing/nvdimm//config_check.o', needed by 'tools/testing/nvdimm//dax.o' kbuild test robot
2016-08-16 0:58 ` Dan Williams
2016-08-16 1:26 ` [kbuild-all] " Fengguang Wu
2016-08-16 1:30 ` Dan Williams
2016-08-16 1:36 ` Fengguang Wu
2016-08-16 1:41 ` Fengguang Wu
2016-08-16 1:47 ` Yilong Ren
2016-08-16 1:58 ` Fengguang Wu [this message]
2016-08-16 2:19 ` Yilong Ren
2016-08-16 2:30 ` Fengguang Wu
2016-08-16 2:33 ` Yilong Ren
2016-08-16 1:48 ` Dan Williams
2016-08-16 1:41 ` Yilong Ren
2016-08-22 12:26 ` Yilong Ren
2016-08-23 23:42 ` Dan Williams
2016-08-24 2:47 ` Fengguang Wu
2016-08-24 14:59 ` Dan Williams
2016-08-25 0:09 ` Fengguang Wu
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=20160816015843.GA12894@wfg-t540p.sh.intel.com \
--to=fengguang.wu@intel.com \
--cc=dan.j.williams@intel.com \
--cc=jthumshirn@suse.de \
--cc=kbuild-all@01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yilongx.ren@intel.com \
/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