linux-kernel - Re: bug: Kbuild seems to require "make prepare-objtool" in order to use (some) new config vars

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNASmVoZequqaj6MTimeZ0MG0fk7Wb5-9haFhgG03kDBpxg@mail.gmail.com>
Date:   Thu, 30 Apr 2020 22:51:48 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>
Subject: Re: bug: Kbuild seems to require "make prepare-objtool" in order to
 use (some) new config vars

Hi Mauro,


On Thu, Apr 30, 2020 at 8:17 PM Mauro Carvalho Chehab
<mchehab+huawei@...nel.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.


./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.


>
> 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.



-- 
Best Regards
Masahiro Yamada