[kbuild-devel] kbuild update
A summary of what is planned to be submitted in next merge window for kbuild. The shortlog below have additional details but the headlines are: o Make the kernel buildable on a cygwin box (but not without a few glitches) o detect unterminated device id list o add export_report as a valid top-level make target o add script to find unused kconfig symbols (try it!) o allow a user to specify additional flags on the commandline with CFLAGS, AFLAGS or CPPFLAGS. The flags will be appended to the kernel defiend flags The CFLAGS change will conflict with Andi's x86 patches and I fix it before pushing if Andi's patches are pushed first. Otherwise no conflicts. The vmlinux.lds changes that I have sent to a number of arch maintainers lately are not included. I expect them to be applied by the respective arch maintainers. The --gc-section cleanup from Denys Vlasenko will be included in kbuild after the merge window so we can try it out in -mm before hitting mainline. Jan Beulich kconfig patch will most likely be included. Need to test it first. Marej menuconfig improvement may also be included. Last patch looked good but have not made up my mind if it really help people. Patched referred below are available at git.kernel.org at kbuild.git in an hour or so. Sam Adrian Bunk (2): kbuild: fix export_report.pl kbuild: call export_report from the Makefile Jesper Juhl (3): kbuild: improve scripts/gcc-version.sh output a bit when called without args kbuild: ver_linux fix glibc version print kbuild: scripts/ver_linux : correct printing of binutils version Kees Cook (1): kbuild: make modpost detect unterminated device id lists Mike Frysinger (1): kbuild: clean Modules.symvers in external module dirs Paolo 'Blaisorblade' Giarrusso (1): kbuild: script to check for undefined Kconfig symbols Petr Stetiar (1): kbuild: fix segfault in modpost Ram Pai (1): kbuild: fix perl usage in export_report.pl Randy Dunlap (1): docproc: style typo cleanups Sam Ravnborg (10): kbuild: Use Elfnn_Half as replacement for Elfnn_Section kbuild: check if we can link gettext not just compile kbuild: fix genksyms Makefile kbuild: __extension__ support in genksyms (fix unknown CRC warning) kbuild: apply genksyms changes kbuild: enable 'make CFLAGS=...' to add additional options to CC kbuild: enable 'make AFLAGS=...' to add additional options to AS ia64: fix sn to add include files using EXTRA_CFLAGS kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP kbuild: fix directory traversal bug Shlomi Fish (1): kconfig: qconf (make xconfig) Search Dialog Enhancement - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Distributed configuration scheme by Linus at. al. (going back in time)
Hallo, Sam. Can try to find exact wording/archives of the subject? http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.1/2004.html Also, please describe what it was from your POV that time back. I'm doing library/history paper work now, before progressing in my design, you know. Happened to see that flame wars in lkml back in post dot.com days. http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.1/1909.html Now it seems to be all dead topic. Hope you will have some time to answer. Thanks. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] kbuild update
On Sun, 16 Sep 2007, Oleg Verych wrote: On Sun, Sep 16, 2007 at 08:58:03AM -0400, Robert P. J. Day wrote: On Sun, 16 Sep 2007, Sam Ravnborg wrote: A summary of what is planned to be submitted in next merge window for kbuild. The shortlog below have additional details but the headlines are: ... o add script to find unused kconfig symbols (try it!) based on my experiences with this, unless you filter carefully, you're going to end up with a *whack* of false positives given the number of developers who elect to name their local macros starting with a prefix of CONFIG_. good luck dealing with *that*. :-) I saw you patches about that kconfig symbols usage, your developments of *the* script. I also happened to see `linux-2.4.X/checkconfig.pl`. Now somebody else proposed something related to kbuild tree. So, what was your point in doing that, why your work didn't ended up in `linux/scripts/'? i've never looked at checkconfig.pl, i didn't even know it existed. i just wrote a simple shell script that scanned for the obvious occurrence of CONFIG_FUBAR symbols for which there is no corresponding FUBAR definition in a Kconfig* file somewhere. i think i can guarantee that i won't *miss* any but, as i've mentioned before, i definitely display a lot of false positives based on developers' less-than-ideal choice of macro names, and i just haven't put any effort into filtering those out since it doesn't seem worth the time. as for adding a check like that to the Kbuild structure itself, i get the feeling that you'd run into the same philosophy as adding a debugger to the kernel would get you. i don't think it's worth over-complicating the Kbuild structure -- i think it's just easier to leave stuff like that as external, cheap, one-off utility scripts. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Distributed configuration scheme by Linus at. al. (going back in time)
Hi Oleg. On Sun, Sep 16, 2007 at 03:12:48PM +0200, Oleg Verych wrote: Hallo, Sam. Can try to find exact wording/archives of the subject? http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.1/2004.html Also, please describe what it was from your POV that time back. I'm not sure exactly what you are after here. Are you asking to the actual kbuild-2.5 versus mainline kbuild story or are you asking for an opinion on a specific subject? Your mail subject and the mail content confuses me - I do not see the relation. Sam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] kbuild update
On Sun, 16 Sep 2007, Sam Ravnborg wrote: On Sun, Sep 16, 2007 at 08:58:03AM -0400, Robert P. J. Day wrote: On Sun, 16 Sep 2007, Sam Ravnborg wrote: A summary of what is planned to be submitted in next merge window for kbuild. The shortlog below have additional details but the headlines are: ... o add script to find unused kconfig symbols (try it!) based on my experiences with this, unless you filter carefully, you're going to end up with a *whack* of false positives given the number of developers who elect to name their local macros starting with a prefix of CONFIG_. good luck dealing with *that*. :-) This is useful for specific people but not for kernel janitorial fodder. As you already experience the amount of false positive are too high. But for a developer of a module it is no deal to ignore the false positives. It is for godd reasons not integrated in the build process. right, i agree completely. if it were absolutely reliable in generating *only* actual unused symbols, then that *might* (i stress, *might*) be a viable argument for making it part of the Kbuild system. but, really, if you can whip off a script that does most of the job in a few minutes, there's really no motivation to then spend hours trying to nail those last few harmless bits of irrelevant output. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Distributed configuration scheme by Linus at. al. (going back in time)
On Sun, Sep 16, 2007 at 05:11:12PM +0200, Sam Ravnborg wrote: Hi Oleg. On Sun, Sep 16, 2007 at 03:12:48PM +0200, Oleg Verych wrote: Hallo, Sam. Can try to find exact wording/archives of the subject? http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.1/2004.html Also, please describe what it was from your POV that time back. I'm not sure exactly what you are after here. There is your comment about Linus, describing distributed (or whatever) kconfig. I'd like to have link to read archives, if you can find it. [] are you asking for an opinion on a specific subject? Yes also. Specific as in the Subject:, please. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Distributed configuration scheme by Linus at. al. (going back in time)
On Sun, Sep 16, 2007 at 05:40:00PM +0200, Oleg Verych wrote: On Sun, Sep 16, 2007 at 05:11:12PM +0200, Sam Ravnborg wrote: Hi Oleg. On Sun, Sep 16, 2007 at 03:12:48PM +0200, Oleg Verych wrote: Hallo, Sam. Can try to find exact wording/archives of the subject? http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.1/2004.html Also, please describe what it was from your POV that time back. I'm not sure exactly what you are after here. There is your comment about Linus, describing distributed (or whatever) kconfig. I'd like to have link to read archives, if you can find it. [] are you asking for an opinion on a specific subject? Yes also. Specific as in the Subject:, please. CML2 had all config in a single file IIRC. Kconfig has it distributed all over the tree. If you need more please elaborate a bit more. Thanks, Sam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Distributed configuration scheme by Linus at. al. (going back in time)
On Sun, Sep 16, 2007 at 07:02:27PM +0200, Sam Ravnborg wrote: [] CML2 had all config in a single file IIRC. Kconfig has it distributed all over the tree. If you need more please elaborate a bit more. Ahh, i thought about another kind of distribution of configuration. Namely items, not files, because latter is obvious :). But this is another story, which is, hopefully, not a repetition of the history, like those CONFIG_ cleanups over and over by ESR at. al. Goodbye. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [patch 01/03] kbuild, asm-values: infrastructure
Hi Oleg. On Wed, Jun 13, 2007 at 01:36:51AM +0200, Oleg Verych wrote: * header with widely used value definitions * handle all asm-related things in one file (Makefile.asm) * move some asm bits from Makefile.build there (rule %.s:%.c) * add script to generate headers from assembles output (hopefully better output, MIPS testing/joining to all arch probably needed) Took a look at this patch at last. Your patch moves everything to Makefile.asm and uses a script to generate the offset file. Now where we go the step to use a script to generate the offset file a much simpler approach would be to move both steps to the shell script. So the script are called with the input file as one of the arguments and it spits out the resulting file to stdout. Doing it this way would allow the caller to have full control on the filenames and the current call-site in top-level Kbuild would still be much simpler than today. Moving the bits from Makefile.build that is only used for asm-offset is a nice cleanup and this should the script version support too. I see no value in renaming from asm_offset to asm_value - please drop it. Introducing the generic asm-values.h should wait and when you do you should be preapred to update all architectures (ecasue otherwise it will not happen). Sorry for the late feedback. Sam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Rename asm-offsets tool or not? (Re: [patch 01/03] kbuild, asm-values: infrastructure)
On Sun, Sep 16, 2007 at 09:32:58PM +0200, Oleg Verych wrote: On Sun, Sep 16, 2007 at 08:29:12PM +0200, Sam Ravnborg wrote: Hi Oleg. Hallo. Nice, you are bringing it back. I'll try to have LKML-like output this time, not a makefile mess and stuff: [] I see no value in renaming from asm_offset to asm_value - please drop it. Introducing the generic asm-values.h should wait and when you do you should be preapred to update all architectures (ecasue otherwise it will not happen). All archs, are using same syntax. But. Interesting exception is MIPS, where tokens are organized and implemented more nicely, that is where *asm-values* name coming from, actually. One can see all that text, size, constant tokens in addition to just offsets. So, if name change isn't worth, then OK; filename compatibility check, as one in `linux/Kbuild', is easy to hack as well to remove. But nice feature/tool with meaningful name and functionality is just another thing. Opinions? Everyone and their cousin these days knows that asm-offset is constants generated from C and used in assembler. If we benefit from more values in the asm-offset file - let's do it. But there is no reason to change a name that has been used for this purpose for as long as I can remember. Sam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
