linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: bug: Kbuild seems to require "make prepare-objtool" in order to use (some) new config vars
Date: Thu, 30 Apr 2020 18:49:48 +0200	[thread overview]
Message-ID: <20200430184948.27191975@coco.lan> (raw)
In-Reply-To: <CAK7LNASmVoZequqaj6MTimeZ0MG0fk7Wb5-9haFhgG03kDBpxg@mail.gmail.com>

Em Thu, 30 Apr 2020 22:51:48 +0900
Masahiro Yamada <masahiroy@kernel.org> escreveu:

> Hi Mauro,
> 
> 
> On Thu, Apr 30, 2020 at 8:17 PM Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> >
> > Hi Masahiro,
> >
> > Not sure if this was already reported (or eventually fixed) upstream.
> >
> > While doing a Kconfig reorg on media, I noticed a few weird things,
> > requiring me to call, on a few situations, "make modules_prepare"
> > manually after some changes.
> >
> > I'm now working on a patchset to yet to be merged upstream aiming to
> > resurrect a driver from staging. It is currently on this tree
> > (with is based at the media development tree, on the top of 5.7-rc1):
> >
> >         https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp_v2
> >
> > There, I was able to identify a misbehavior that it is probably
> > what forced me to need calling "make modules_prepare".
> >
> > The atomisp driver is on a very bad shape. Among its problems, it has a
> > set of header definitions that should be different for two different
> > variants of the supported devices. In order to be able to compile for
> > either one of the variants, I added a new config var:
> > CONFIG_VIDEO_ATOMISP_ISP2401.
> >
> > The problem is that calling just
> >
> >         ./scripts/config -e CONFIG_VIDEO_ATOMISP_ISP2401
> >
> > or
> >         ./scripts/config -d CONFIG_VIDEO_ATOMISP_ISP2401  
> 
> 
> scripts/config does not take the dependency into consideration
> at all.
> 
> You need to enable/disable other options that it depends on.

Yes, I know. on my tests, I did a "make allyesconfig" before
the patch whose added this dependency. So, the only dependency
left to be enabled or disabled was this one.

The problem I'm pointing is not really do a select recursion
(that would be a really cool feature, but I know it is not
trivial), but, instead, that, despite the config var was
there, when I tried to build it with:

	make clean; make M=drivers/staging/media/atomisp

It didn't do the right thing. Instead, it used ISP2401=y
on make clean and ISP2401=n at the drivers build.

So, in order to test if patches won't break building,
depending on the value of this var, I'm currently doing:

	cls;./scripts/config -d CONFIG_VIDEO_ATOMISP_ISP2401 && make prepare-objtool && make clean && make M=drivers/staging/media/atomisp && ./scripts/config -e CONFIG_VIDEO_ATOMISP_ISP2401 && make prepare-objtool && make clean && make M=drivers/staging/media/atomisp

(note the alien "make prepare-objtool" in the middle)


> ./scripts/config -e STAGING -e STAGING_MEDIA -e MEDIA_SUPPORT -e
> MEDIA_CONTROLLER -e INTEL_ATOMISP -e VIDEOBUF_VMALLOC -e VIDEO_ATOMISP
> -d MEDIA_SUPPORT_FILTER -e VIDEO_DEV -e VIDEO_V4L2 -e
> VIDEO_ATOMISP_ISP2401
> 
> allows me to enable VIDEO_ATOMISP_ISP2401.
> 
> 
> It is painful to debug such complicated dependency graph, though.

Yeah, dependencies at the media subsystem are usually quite complex.

> >
> > is not enough anymore for the build to actually use the new config value.
> >
> > It just keeps silently using the old config value.
> >
> > I double-checked it by adding this macro at the Makefile:
> >
> >         $(info ************ ISP2401: $(CONFIG_VIDEO_ATOMISP_ISP2401) ************)
> >
> > The Makefile doesn't see the change, except if I explicitly call
> > "make modules_prepare" or "make prepare-objtool".
> >
> > Even calling "make oldconfig" doesn't make it use the new CONFIG_*  
> 
> 
> I do not know.
> 
> I cannot look into it without detailed steps to reproduce it.

I'm applying the enclosed patch to this branch:

	https://git.linuxtv.org/mchehab/experimental.git/log/?h=atomisp_v2

and running this:

	$ make allyesconfig 2>/dev/null >/dev/null; echo "disable";./scripts/config -d CONFIG_VIDEO_ATOMISP_ISP2401 && make M=drivers/staging/media/atomisp && ./scripts/config -e CONFIG_VIDEO_ATOMISP_ISP2401 && echo "enable" && make clean && make M=drivers/staging/media/atomisp
	disable

	  WARNING: Symbol version dump ./Module.symvers
	           is missing; modules will have no dependencies and modversions.
	
	************ ISP2401: y ************
	  AR      drivers/staging/media/atomisp/built-in.a
	************ ISP2401: y ************
	  MODPOST 0 modules
	enable
	************ ISP2401:  ************

	  WARNING: Symbol version dump ./Module.symvers
        	   is missing; modules will have no dependencies and modversions.

	************ ISP2401: y ************
	  AR      drivers/staging/media/atomisp/built-in.a
	************ ISP2401: y ************
	  MODPOST 0 modules

PS.: the same occurs if I use "make allmodconfig".

Thanks,
Mauro


diff --git a/drivers/staging/media/atomisp/Makefile b/drivers/staging/media/atomisp/Makefile
index b0a396cb6bb3..f796cfce2f72 100644
--- a/drivers/staging/media/atomisp/Makefile
+++ b/drivers/staging/media/atomisp/Makefile
@@ -1,9 +1,11 @@
 #
 # Makefile for camera drivers.
 #
-obj-$(CONFIG_INTEL_ATOMISP) += i2c/
-obj-$(CONFIG_INTEL_ATOMISP) += platform/
-obj-$(CONFIG_VIDEO_ATOMISP) += atomisp.o
+
+# HACK: disable all builds
+#obj-$(CONFIG_INTEL_ATOMISP) += i2c/
+#obj-$(CONFIG_INTEL_ATOMISP) += platform/
+#obj-$(CONFIG_VIDEO_ATOMISP) += atomisp.o
 
 atomisp = $(srctree)/drivers/staging/media/atomisp/
 


  reply	other threads:[~2020-04-30 16:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30 11:17 bug: Kbuild seems to require "make prepare-objtool" in order to use (some) new config vars Mauro Carvalho Chehab
2020-04-30 13:51 ` Masahiro Yamada
2020-04-30 16:49   ` Mauro Carvalho Chehab [this message]
2020-04-30 17:20     ` Masahiro Yamada
2020-04-30 19:10       ` Mauro Carvalho Chehab
2020-04-30 19:25         ` [PATCH RFC] Kbuild: Makefile: warn if auto.conf is obsolete Mauro Carvalho Chehab
2020-05-01  3:27           ` Masahiro Yamada
2020-05-01  2:31         ` bug: Kbuild seems to require "make prepare-objtool" in order to use (some) new config vars Masahiro Yamada

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=20200430184948.27191975@coco.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    /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).