linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Sam Ravnborg <sam@ravnborg.org>, Michal Marek <mmarek@suse.com>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Rob Herring <robh@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	Richard Purdie <richard.purdie@linuxfoundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Markus Heiser <markus.heiser@darmarit.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	SeongJae Park <sj38.park@gmail.com>,
	"Yann E. MORIN" <yann.morin.1998@free.fr>
Subject: Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
Date: Sat, 19 Aug 2017 10:14:25 -0700	[thread overview]
Message-ID: <CA+55aFzr2HTZVOuzpHYDwmtRJLsVzE-yqg2DHpHi_9ePsYp5ug@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFzQ4shyD=bqdSMreU33iLVkEsSgnMXegL5wcu5ug0fOUg@mail.gmail.com>

On Sat, Aug 19, 2017 at 10:03 AM, Linus Torvalds
<torvalds@linux-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

  reply	other threads:[~2017-08-19 17:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-19  8:49 [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Masahiro Yamada
2017-08-19  8:49 ` [RFC PATCH 1/3] kbuild: generate *.hash.c during build Masahiro Yamada
2017-08-19  8:49 ` [RFC PATCH 2/3] kbuild: generate *.lex.c " Masahiro Yamada
2017-08-19  8:49 ` [RFC PATCH 3/3] kbuild: generate *.tab.c and *.tab.h " Masahiro Yamada
2017-08-21 17:12   ` Rob Herring
2017-08-19 11:31 ` [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Cao jin
2017-08-19 17:03 ` Linus Torvalds
2017-08-19 17:14   ` Linus Torvalds [this message]
2017-08-19 18:12     ` Linus Torvalds
2017-09-08  6:18     ` Masahiro Yamada
2017-09-08 17:22       ` Linus Torvalds
2017-09-08 18:01         ` Linus Torvalds
2017-09-08 18:39           ` Linus Torvalds
2017-09-08 21:38             ` Linus Torvalds
2017-09-09  6:39               ` Sam Ravnborg
2017-09-10 13:59                 ` Masahiro Yamada
2017-09-10 13:58               ` Masahiro Yamada
2017-09-10 16:27                 ` Linus Torvalds

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=CA+55aFzr2HTZVOuzpHYDwmtRJLsVzE-yqg2DHpHi_9ePsYp5ug@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    --cc=mchehab@kernel.org \
    --cc=mmarek@suse.com \
    --cc=npiggin@gmail.com \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sj38.park@gmail.com \
    --cc=yamada.masahiro@socionext.com \
    --cc=yann.morin.1998@free.fr \
    /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).