Kbuild update

kbuild.git contains at the moment 36 patches which is all for the upcoming merge window. It has been rebased to latest -linus git tree.
See shortlog below.

Pending patches
===============
kbuild:
- Section garbage collection (Denys Vlasenko)
I had too little time to play with it so it will not hit this merge window :-(
- Improved stripping (Jan Beulich)
needs review
- Enhance make rpm (Florin Andrei)
needs review
- merge uboot mkimage (Josh Boyer)
await an update with a renamed script, maybe I already got it

kconfig:
- Access enviromnet variables (Roman Zippel)
seems I have lost the original patch - needs to serach lkml.org
- arch/Kconfig (Mathieu)
(Maybe Andrew have them, needs follow up)
- xconfig search dialog (Shlomi Fish)
needs review + test

Known issues
============
kbuild:
- make rpm are reported buggy
I have plenty of mails with bug reports but no patches and I do not know rpm myself
- zillion of mails from Robert P. J. Day

kconfig:
- Segmentation violation when seeing recursive symbols I added the bug but have not had time to fix it yet

TODO items (from my mailbox - I have plenty more)
=================================================
- asm-offset useable from modules (Oleg had a half backed solution)
- modpost should use err(), warn() etc (suggestyed by Rusty)
- less kernel hardcoding in kconfig (Rob Landley)
- emit dependencies from "depends" (Bernhard Fischer)
- fix select (whatever that means)
- allow kconfig to accept overrides (Jan Engelhart)
maybe there is a patch, needs followup
- document kernel build better (Andreas Hermann)
just a start, more is needed
- save ARCH and CROSSCOMPILE
requires major surgery to do correct - we use CC too early
- i18n patch for mconf and friends (from Kernel Translator project) is old but several bits of it needs to be applied to better support i18n
- i18n support in kernel
some like it, others don't. But now we have japanese versions of some docs...
- use GCC --combine (David Woodhouse)
- more color themes (Jan Engelhart)
and I would like them selectable from inside menuconfig
- walk throug the ~15 qconf related patched - are they relevant?
- document use of __init and related sections
- Use seperate sections for all init sections to improve checking
- improve headers_check (10x speed up is possible by doing a dir-by-dir check)

bugzilla.kernel.org
===================
7103 [email protected] NEW 2.6.17.* initramfs problem
3174 [email protected] ASSI 2.6.7 make rpm creates erroneous version number
3486 [email protected] ASSI 2.6.4-52 "make clean" on external driver will clean the kernel sou...
6860 [email protected] ASSI 2.6.18-rc1 'make deb-pkg' create incorrect package name
7042 [email protected] ASSI 2.6.17.7 Recursing into /lib/modules/uname -r/build infects my b...
8275 [email protected] ASSI 2.6.21-rc5-g28d... make rpm-pkg broken for git cloned sources

On top of this I have my personal todo items such as:
- document kconfig a bit
- make it possible to include all kconfig files
- clean up kconfig files
- documet use of HAVE_ in kconfig files
- modern ncurses interface for menuconfig (ala tig, htop and others)
- etc...

So all in all no reasons to be bored.
Did you send me a patch that is neither listed above nor below then please resend. Any help with the above are much appreciated!

Note: The kbuild stuff is done only in my spare time and
with 3 kids, a wife and a full-time job I am often lacking behind.

Sam

Adrian Bunk (1):
Remove references to "make dep"

Andi Kleen (3):
kbuild: declare the modpost error functions as printf like
kbuild: fix format string warnings in modpost
kbuild: fix a buffer overflow in modpost

Andreas Mohr (1):
kbuild: eradicate bashisms in scripts/patch-kernel

Andres Salomon (1):
kconfig: use getopt() in conf.c for handling command line arguments

Aron Griffis (1):
kbuild: support mercurial in setlocalversion

Geert Uytterhoeven (1):
kbuild: Add missing srctree prefix for includecheck and versioncheck

Johannes Berg (7):
kernel-doc: fix xml output mode
kernel-doc: init kernel version
kernel-doc: single DOC: selection
kernel-doc: process functions, not DOC:
kernel-doc: use no-doc option
kernel-doc: new P directive for DOC: sections convert drivers/base/power/Makefile to ccflags

Ladislav Michl (1):
kconfig: make kconfig MinGW friendly

Mike Frysinger (1):
kbuild: fixup genksyms usage/getopt

Randy Dunlap (2):
kbuild: add 'includecheck' help text
kconfig: add hints/tips/tricks to Documentation/kbuild/kconfig-language.txt

Robert P. J. Day (2):
Kbuild: Clarify the rpm-related make packaging targets A few corrections to include/linux/Kbuild

Sam Ravnborg (5):
kbuild: document versioncheck in make help
kconfig: if ncurses-devel is missing then say so
kbuild: fix buglet in gcc-version.sh
kbuild: ignore *.order files
kbuild: fix installing external modules

Tejun Heo (1):
kbuild: implement modules.order

Theodore Ts'o (3):
kbuild: change CONFIG_LOCALVERSION_AUTO to use a git-describe-ish format
kbuild: fix scripts/setlocalversion to avoid erroneous -dirty tag
kbuild: fix false positive -dirty tag caused by make-kpkg

Vegard Nossum (1):
aic7(3*x): fix firmware build

WANG Cong (5):
MIPS: Remove 'TOPDIR' from Makefiles
CRIS: Remove 'TOPDIR' from Makefiles
INFINIBAND: Remove 'TOPDIR' from Makefiles
FRV: Drop 'TOPDIR' from Makefiles
FS: Remove dead code

The full diffstat is:

 .gitignore                                  |    1 +
 Documentation/kbuild/kconfig-language.txt   |   54 +++++++++++++++--
 Makefile                                    |   15 ++++-
 arch/arm/mach-imx/Makefile                  |    3 -
 arch/arm/mach-netx/Makefile                 |    3 -
 arch/cris/arch-v32/boot/compressed/Makefile |    2 +-
 arch/frv/boot/Makefile                      |    8 +-
 arch/frv/kernel/gdb-stub.c                  |    2 +-
 arch/mips/lasat/image/Makefile              |    4 +-
 arch/mips/tx4927/common/Makefile            |    4 -
 arch/mips/tx4938/common/Makefile            |    4 -
 arch/mips/tx4938/toshiba_rbtx4938/Makefile  |    4 -
 arch/sh64/kernel/Makefile                   |    4 -
 arch/sh64/lib/Makefile                      |    4 -
 arch/sh64/mach-cayman/Makefile              |    4 -
 arch/sh64/mm/Makefile                       |    4 -
 arch/xtensa/mm/Makefile                     |    4 -
 arch/xtensa/platform-iss/Makefile           |    5 --
 drivers/base/power/Makefile                 |    8 +--
 drivers/infiniband/hw/cxgb3/Makefile        |    3 +-
 drivers/scsi/aic7xxx/Makefile               |   45 ++++++---------
 fs/smbfs/Makefile                           |   20 ------
 include/linux/Kbuild                        |    8 +-
 scripts/Makefile.build                      |   17 +++++-
 scripts/Makefile.lib                        |    6 ++
 scripts/Makefile.modinst                    |    2 +-
 scripts/basic/docproc.c                     |   44 +++++++++++++-
 scripts/gcc-version.sh                      |    5 +-
 scripts/genksyms/genksyms.c                 |   10 ++-
 scripts/kconfig/Makefile                    |   14 +++--
 scripts/kconfig/conf.c                      |   24 ++++----
 scripts/kconfig/lxdialog/check-lxdialog.sh  |   16 +++--
 scripts/kconfig/lxdialog/dialog.h           |    5 +-
 scripts/kconfig/lxdialog/util.c             |   32 +++++++----
 scripts/kconfig/mconf.c                     |   61 +++----------------
 scripts/kernel-doc                          |   85 ++++++++++++++++++--------
 scripts/mod/modpost.c                       |   18 ++++--
 scripts/package/Makefile                    |    5 +-
 scripts/patch-kernel                        |   22 +++----
 scripts/setlocalversion                     |   29 +++++++++-
 40 files changed, 338 insertions(+), 270 deletions(-)

[snip]

I'm reworking right now actually. Will post an updated version with the binary renamed shortly. I'll be sure to CC you when I do.

josh

Sorry.. your comparison {menuconfig, htop} raises an "incompatible pointer passed" on my side. Please explain :)

Indeed there is/was a patch. Well, the one I sent last time.
http://lkml.org/lkml/2007/10/18/206

I have updated it to Linus's current treetop.
git://computergmbh.de/linux 'kconfig' branch;

===

commit da9389c3e640f9ee261865beb6b9861fe5b30b78

Author: Jan Engelhardt <[email protected]>
Date:   Thu Jan 3 23:23:38 2008 +0100

kconfig: allow overriding symbols

Allow config variables in .config to override earlier ones in the same file. In other words,

# CONFIG_SECURITY is not defined
CONFIG_SECURITY=y

will activate it. This makes it a bit easier to do

cat original-config myconfig myconfig2 ... >.config;

and run *config as expected.

index e0f402f..2853ca7 100644
@@ -232,8 +232,7 @@ load:
 					sym->type = S_BOOLEAN;
 			}
 			if (sym->flags & def_flags) {
-				conf_warning("trying to reassign symbol %s", sym->name);
-				break;
+				conf_warning("override: reassigning to symbol %s", sym->name);
 			}
 			switch (sym->type) {
 			case S_BOOLEAN:

@@ -272,8 +271,7 @@ load:
 					sym->type = S_OTHER;
 			}
 			if (sym->flags & def_flags) {
-				conf_warning("trying to reassign symbol %s", sym->name);
-				break;
+				conf_warning("override: reassigning to symbol %s", sym->name);
 			}
 			if (conf_set_sym_val(sym, def, def_flags, p))
 				continue;

@@ -297,11 +295,9 @@ load:
 				}
 				break;
 			case yes:
-				if (cs->def[def].tri != no) {
-					conf_warning("%s creates inconsistent choice state", sym->name);
-					cs->flags &= ~def_flags;
-				} else
-					cs->def[def].val = sym;
+				if(cs->def[def].tri != no)
+					conf_warning("override: %s changes choice state", sym->name);
+				cs->def[def].val = sym;
 				break;
 			}
 			cs->def[def].tri = E_OR(cs->def[def].tri, sym->def[def].tri);

htop is a nice ncurses based interface to top.

Try "F2" and see a nice layout for a menu structure remotely similar to menuconfig.
I could mention a few more - this was more to say that there exist much beter looking ncurses based tools than menuconfig.

Applied after fixing one checkpatch error.
I did not care about the lines longer than 80 in this case. I also restored the original Cc: list.

Sam

I cannot really think how htop F2 would even be CLOSE to menuconfig. Just that we are talking about the same thing:
http://jengelh.hopto.org/GFX0/htopf2.png
hell no, menuconfig looks much nicer than that.

hm, I can only think of mc right now.

{snip}

Hmm, I glanced at that project. It's old and seems freezed now. I don't know if people still have interests in the i18n of kconfig. If so, I think I can help with the Chinese part. ;)

Well, in fact, we've already had some Chinese docs too. ;) Just have a look at Documentation/zh_CN/.

I will take a look at the problems and see if I can help you.

{snip}

Thanks for your work, Sam!

From the off-list communication I have had there is indeed an interest. It sort of stopped at one point due to missing integration in mainline. What I refer to is mostly the mconf.c bits, but I would also like to see what lkml says to a sample of .po files included in the kernel for a number of languages.

One criteria to get a .po file integrated could be at least 10% of the strings translated or similar.

Sam

Besides the initial translation efforts a big problem would be to also find people who will regularly update the translations for many years.

Otherwise the next round of spelling fixes will push this far below 10%...

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Well, I think it's worthy. The translation effort will be valuable and much helpful for non-English-speaking peoples.

Yes, that's really a problem. But I think the updates won't be too frequent, only update for stable release is enough.

If we can make this to be an offical project for Linux kernel, I think it won't be a big problem.

Regards.

Cong

"only" is the wrong word in this context.

If someone would update the translations for one language every 3 months for the next years that would be great and disprove my concerns.

After all, updates every 3 months would beat the maintainance level of at least three of our architectures...

And don't underestimate the amount of work required - even when talking about requiring "only" 10% of the help texts translated that's a four digit number of lines to translate.

We don't even manage to maintain the English language texts properly, and I am therefore not overly optimistic that we'll have the translations maintained properly for many years.

OTOH, if someone wouldn't just blindly translate the outdated English texts but also review the English texts when translating this alone might be worth it...

cu
Adrian

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

The .pot file is 80601 lines long and contains 11485 strings. [Not counting cris architecture specific strings as it failed]

Italian was 100% translated at one point in time.
And the Linux Kernel Translation project has a number of spelling error fixes in queue (I dunno if they have been applied).

So even when run as an external project it was ok for some languages, and having it official and someone taking patches to .po files would for sure allow more users to build a kernel.

Sam

Agreed.

That's the goal of TLKTP. Sam, can you contact to the author of TLKTP? Maybe we can talk to him to see if we can restart the project. If so, I can help with the Chinese translation part.

Best regards.

Cong

My first try bounced, found another address for Egry Gabor - let's see if I have more luck.

The associated list is spam only so I did not try that one.

Sam

Hmm, yes.

Thanks for your point. I agree that the initial work is not so easy.

Fully agreed.

Maybe we can restart TLKTP?

"I will use ...
http://images.google.cz/images?svnum=100&um=1&hl=cs&client=firefox-a&rls=org.mozilla%3Acs%3Aofficial&q=I+will+use+Google+before&btnG=Hledat+obr%C3%A1zky
... for making translations..."
http://www.google.com/translate?u=http%3A%2F%2Flxr.linux.no%2Flinux%2FDocumentation%2FHOWTO&langpair=en%7Czh-TW&hl=en&ie=UTF8
?

In case if people will help Google to have better quality of translation, that will be better generally for much bigger number of *people*, especially in China, isn't it?

Making any official world-domination/new-world-order projects with Linux will not help IMHO. Very fast code flow and almost no up to date documentation is still relevant and google search + email archives are not going to be obsolete in the near future.

Also, future of the linux codebase with Chinese comments in C or in ASM is kind of wired nightmare. Those, who cannot read actual source code (i.e. C) will not go too far.

So, translation guys, maybe you will stop making noise and will start to make e.g. less buggy Linux? Greg KH have much more stuff to care, than some translations IMHO.

_______

$subject is purely about the kernel configuration - if that was not clear.

Sam

Perhaps yes.

But at least now, that kind of translation still sucks. It can satisfy me.

I never say to translate C comments. What we want to translate is the strings in Kconfig.

I abosutely agree that we should focus on the exsiting bugs of Linux, but like Greg's inclusion of some kernel doc translations, this kind of work is really helpful to attract some kernel newbies from none English-speaking countries. Even we can't make offical efforts, the civil work, like TLKTP, is still worthy. Believe me, I am leading a local LUG in my college and I found that one _big_ reason that why the newbies are afraid of Linux kernel is English, instead of the C tricks or low-level programming.

Regards.

Cong

ftp://flower.upol.cz/upload/Configure.help

OK, please, take a look at stuff, Korean guys did 5-6 years ago. One particular ARM port (S3C2410X) along with an ARM bootloader (vivi) was done. Yet for some reason official Linux port has another developers, and, it seems, it was done some time (~1-2 years) later.

...

IMHO, there is so much stuff done, that any brilliant C or whatever-asm coder *have* to study at least something of it. And, in order to do a valuable contribution, one must know the work-flow, people *and* English. This is usually done by reading mailing list *and* archives for quite some time. This takes time, this takes effort, but this also have huge impact on intelligence and culture of the `coders'.

Do you ever have a question about why History exists and is studied on all levels of education? Same with programming. Without history-via-English, one have no strong roots, thus base for grow and flower.

OTOH, Internet has so much noise and crap all over the place, that information is very hard to find. It takes much time to sort and see it. Yet, providing noise generating, like in-tree translations, seems, is a very easy way around (not taking maintaining in account).
____

I glanced at the page. I don't know Korean, but it seems OK. What do you mean by saying this? I can't catch your points.

I think you've overstated.

Translation does _not_ mean avoiding learning English. I agree with what you said above about English. But just as you said, it needs _time_ and translation *is* a good way to help this. I, myself, began to learn computer English by reading the translations of some famous English textbooks, and then reading the original ones.

Translations can be put in .po files.

Thanks.

Cong