linux-kernel - Re: [GIT PULL 1/2] Kbuild updates for v4.15

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] [day] [month] [year] [list]

Message-ID: <CAK7LNATe7K3A+sYDfsoqLnFq6-fu0=meG_77Fc8HQ5BzkBA2GQ@mail.gmail.com>
Date:   Tue, 21 Nov 2017 00:48:32 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL 1/2] Kbuild updates for v4.15

Hi Linus,


2017-11-20 3:02 GMT+09:00 Linus Torvalds <torvalds@...ux-foundation.org>:
> On Sun, Nov 19, 2017 at 2:40 AM, Masahiro Yamada
> <yamada.masahiro@...ionext.com> wrote:
>>>
>>> FWIW, I still think we should probably make the compiler versions etc
>>> available to the configuration management rather than necessarily
>>> cache them.
>>
>> Do you mean something like this?
>>
>> https://lkml.org/lkml/2016/12/9/577
>
> Yes. With the important part not being so much that particular syntax,
> but the concept of "get some config options from automation".
>
> And the most obvious thing to do would be to just initialize a "bool"
> variable by running a script where the end result is either success or
> failure.
>
> Now, the actual example:
>
>    config COMPILER_SUPPORTS_XYZ
>        bool
>        option shell="gcc -XYZ"
>
> is obviously too simplified to be realistic, because it would have to
> account for the actual compiler setup, so what you really need is not
> "just execute a shell command" but the equivalent of the Makefile
> "cc-option" function. Aes, for "known buggy versions" you might want
> to also get the actual compiler version into a config option.
>
>
>
> Even if "cc-option" is the _only_ thing you can do (and not some kind
> of "generic shell escape"), I think that would be very useful.
> Wouldn't it be nice to be able to have all those Makefile things as
> Kcconfig scripts - and be able to very naturally take them into
> account when offering people some Kconfig options?
>
> So you could do all the logic of not only testing what flags the
> compiler supports, but then use the Kconfig language to _combine_ that
> knowledge with the build options. Both in the sense of "this kernel
> config option depends on the compiler supporting flag XYZ" but also in
> the sense of "the use flag ABC depends on not only compiler support,
> but also on whether the kernel was configured for profiling" or
> whatever.
>
> Then the actual Makefile parts would be things like
>
>     CFLAGS-$(CONFIG_CC_SPLIT_DWARF) += -gsplit_dwarf
>
> because the Kconfig phase would already have all the logic for whether
> (a) gcc actually supports -gsplit-dwarf at all and (b) whether the
> user actually asked for split debug info.
>
> And we'd not have the performance issues that made that whole caching
> thing be an issue, because the actual gcc support testing would only
> happen at Kconfig time.
>
> .. it would also make the caching rules be obvious. It's just a "if
> you upgraded or changed compilers enough to be noticeable, re-do your
> config ('make oldconfig')".
>
>                Linus

OK, probably this is the right direction.

Embedded folks need to agree to give CROSS_COMPILE to the Kconfig phase.





-- 
Best Regards
Masahiro Yamada