linux-kernel - Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 13 Jun 2018 08:55:22 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        masahiroy@...nel.org
Subject: Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

On Wed, Jun 13, 2018 at 7:47 AM Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
>
> Please pull more Kbuild updates.

Pulled. However, I notice a few oddities.

This causes a non-clang build to have

    CLANG_VERSION=0

in the config file. Maybe that's intentional to simplify other
expressions (ie allow "depends on CLANG_VERSION > xyz" elsewhere), but
it does look a bit odd. It looks like GCC_VERSION does the same. But
wouldn't that work even if  it's undefined (I didn't check the Kconfig
language rules)?

So if it _wasn't_ intentional, maybe add a

        depends on CC_IX_xyz

to the 'xyz_VERSION' config options? That would seem to be a bit more
logical to me.

Also, we already had one bug in the compiler detection due to the grep
looking at the wrong lines earlier. Shouldn't we have some sanity
checking of the CC_IS_xyz things?

IOW, maybe we should error out if we see *both* CC_IS_GCC and
CC_IS_CLANG, but also if we see neither?

Other than those small nit-picks, I  really like how it's more
legible, in addition to this part:

 26 files changed, 173 insertions(+), 308 deletions(-)

Thanks,

          Linus