Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1728622
| From | Masahiro Yamada <yamada.masahiro@socionext.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files |
| Date | 2017-09-08 08:20 +0200 |
| Message-ID | <unkNY-2TR-3@gated-at.bofh.it> (permalink) |
| References | <ug7LP-7ue-5@gated-at.bofh.it> <ugfq2-42G-7@gated-at.bofh.it> <ugfzI-45T-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Linus, Very sorry that I had not responded quickly. When I was digging into tool version dependency, as you pointed out, gperf is a problem (but seemed one time breakage for gperf 3.1) flex seemed very stable for a long time. bison seemed a bit problem if old version is used. But, I did not have enough time to take a closer look. I thought I should respond after I tested more, but I has been pressed by my daily tasks, then time passed... Very sorry. Today, I just noticed gperf usage got dropped from the kernel. If CONFIG_MODVERSIONS is enabled, I notice lots of error messages. WARNING: EXPORT symbol "finish_open" [vmlinux] version generation failed, symbol will not be So, I think something was broken in scripts/genksyms/. Of course, it was a trivial conversion, so it should not be hard to fix... > 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. One idea may be to process the output of "gperf -v" and embed GPERF_VERSION into the output .c files. But, if you are unhappy with gperf breakage this time, we can live without gperf. > It's likely not even any slower, but who the hell knows.. Do we even > care? It's almost certainly faster if you compare to generating that > gperf code. > For scripts/kconfig/, I think we do not care at all because we usually invoke it just once when we configure the build setting. If we enable CONFIG_MODVERSIONS, scripts/genksyms/ is invoked over and over again. Sorry, I have not evaluated if the perfect hash gives us noticeable advantage or not.. -- Best Regards Masahiro Yamada
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-09-08 08:20 +0200
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-08 19:30 +0200
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-08 20:10 +0200
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-08 20:40 +0200
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-08 23:40 +0200
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Sam Ravnborg <sam@ravnborg.org> - 2017-09-09 08:40 +0200
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-09-10 16:10 +0200
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-09-10 16:00 +0200
csiph-web