From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932386AbcHPB6u (ORCPT ); Mon, 15 Aug 2016 21:58:50 -0400 Received: from mga03.intel.com ([134.134.136.65]:60494 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932225AbcHPB6s (ORCPT ); Mon, 15 Aug 2016 21:58:48 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,528,1464678000"; d="scan'208";a="749180832" Date: Tue, 16 Aug 2016 09:58:43 +0800 From: Fengguang Wu To: Yilong Ren Cc: Dan Williams , Johannes Thumshirn , kbuild-all@01.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'. Message-ID: <20160816015843.GA12894@wfg-t540p.sh.intel.com> References: <201608151849.0GQ0EGLP%fengguang.wu@intel.com> <20160816012659.GA9457@wfg-t540p.sh.intel.com> <20160816014102.GC10769@wfg-t540p.sh.intel.com> <20160816014751.GC6835@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20160816014751.GC6835@localhost.localdomain> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 >> >>> 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