linux-kernel - Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying

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: <CA+55aFzr2HTZVOuzpHYDwmtRJLsVzE-yqg2DHpHi_9ePsYp5ug@mail.gmail.com>
Date:   Sat, 19 Aug 2017 10:14:25 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Sam Ravnborg <sam@...nborg.org>, Michal Marek <mmarek@...e.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Rob Herring <robh@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Richard Purdie <richard.purdie@...uxfoundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Markus Heiser <markus.heiser@...marit.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        SeongJae Park <sj38.park@...il.com>,
        "Yann E. MORIN" <yann.morin.1998@...e.fr>
Subject: Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of
 copying _shipped files

On Sat, Aug 19, 2017 at 10:03 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> So one of the advantages of the pre-shipped files is that we can avoid
> that kind of crazy version issues with the tools.

Side note: the traditional way to handle this is autoconf etc. Since I
think autoconf is evil crap, I refuse to have anything what-so-ever to
do with it.

gperf is clearly written by clowns that don't understand about
compatibility issues - it would have been trivial for them to add some
kind of marker define so that you could test for this directly rather
than depend on some kind of autoconf "try to build and see if it
fails" crap.

So I think the best option would be to jhust get rid of gperf, and use
a normal hash function instead (even if it isn't "perfect" - it's not
like perfect hashes are so wonderful).

I wonder if those two ID lookups are even worth hashing at all - the
arrays aren't so big, and the uses aren't so timing-critical, so it's
entirely possible that we could just get rid of any hashing at all and
just use some stupid linear search thing.

I assume that flex/bison are stable enough that we don't have the same
kind of annoying stupid version issues with it.

Anybody want to look at just getting rid of the gperf use?

                  Linus