Kbuild update

Kbuild update

[Sam Ravnborg]

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 	sam@ravnborg.org 	NEW 		2.6.17.* 	initramfs problem
3174 	sam@ravnborg.org 	ASSI 		2.6.7 	        make rpm creates erroneous version number
3486 	sam@ravnborg.org 	ASSI 		2.6.4-52 	"make clean" on external driver will clean the kernel sou...
6860 	sam@ravnborg.org 	ASSI 		2.6.18-rc1 	'make deb-pkg' create incorrect package name
7042 	sam@ravnborg.org 	ASSI 		2.6.17.7 	Recursing into /lib/modules/`uname -r`/build infects my b...
8275 	sam@ravnborg.org 	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(-)

Re: Kbuild update

[Josh Boyer]

On Thu, 3 Jan 2008 22:32:55 +0100
Sam Ravnborg <sam@ravnborg.org> wrote:

> 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:
[snip]

> - merge uboot mkimage (Josh Boyer)
>   await an update with a renamed script, maybe I already got it

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

Re: Kbuild update

[Jan Engelhardt]

On Jan 3 2008 22:32, Sam Ravnborg wrote:
>
>On top of this I have my personal todo items such as:
>- modern ncurses interface for menuconfig (ala tig, htop and others)

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


>TODO items (from my mailbox - I have plenty more)
>=================================================
>- allow kconfig to accept overrides (Jan Engelhart)
>  maybe there is a patch, needs followup

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 <jengelh@computergmbh.de>
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.
    
    Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index e0f402f..2853ca7 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -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);

Re: Kbuild update

[Sam Ravnborg]

On Thu, Jan 03, 2008 at 11:33:44PM +0100, Jan Engelhardt wrote:
> 
> On Jan 3 2008 22:32, Sam Ravnborg wrote:
> >
> >On top of this I have my personal todo items such as:
> >- modern ncurses interface for menuconfig (ala tig, htop and others)
> 
> Sorry.. your comparison {menuconfig, htop} raises an "incompatible
> pointer passed" on my side. Please explain :)

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.

> 
> >TODO items (from my mailbox - I have plenty more)
> >=================================================
> >- allow kconfig to accept overrides (Jan Engelhart)
> >  maybe there is a patch, needs followup
> 
> 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;

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

Re: Kbuild update

[Jan Engelhardt]

On Jan 4 2008 20:43, Sam Ravnborg wrote:
>On Thu, Jan 03, 2008 at 11:33:44PM +0100, Jan Engelhardt wrote:
>> 
>> On Jan 3 2008 22:32, Sam Ravnborg wrote:
>> >
>> >On top of this I have my personal todo items such as:
>> >- modern ncurses interface for menuconfig (ala tig, htop and others)
>> 
>> Sorry.. your comparison {menuconfig, htop} raises an "incompatible
>> pointer passed" on my side. Please explain :)
>
>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 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.

>I could mention a few more - this was more to say that there
>exist much beter looking ncurses based tools than menuconfig.

hm, I can only think of mc right now.

Re: Kbuild update

[WANG Cong]

{snip}

>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

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. ;)


>- i18n support in kernel
>  some like it, others don't. But now we have japanese versions of some docs...

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


>- 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 	sam@ravnborg.org 	NEW 		2.6.17.* 	initramfs problem
>3174 	sam@ravnborg.org 	ASSI 		2.6.7 	        make rpm creates erroneous version number
>3486 	sam@ravnborg.org 	ASSI 		2.6.4-52 	"make clean" on external driver will clean the kernel sou...
>6860 	sam@ravnborg.org 	ASSI 		2.6.18-rc1 	'make deb-pkg' create incorrect package name
>7042 	sam@ravnborg.org 	ASSI 		2.6.17.7 	Recursing into /lib/modules/`uname -r`/build infects my b...
>8275 	sam@ravnborg.org 	ASSI 		2.6.21-rc5-g28d... 	make rpm-pkg broken for git cloned sources
>

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

{snip}

>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.

Thanks for your work, Sam!

Re: Kbuild update

[Sam Ravnborg]

On Fri, Jan 04, 2008 at 09:23:16PM +0800, WANG Cong wrote:
> 
> {snip}
> 
> >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
> 
> 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. ;)

>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

Re: Kbuild update

[Adrian Bunk]

On Fri, Jan 04, 2008 at 03:39:53PM +0100, Sam Ravnborg wrote:
> On Fri, Jan 04, 2008 at 09:23:16PM +0800, WANG Cong wrote:
> > 
> > {snip}
> > 
> > >TODO items (from my mailbox - I have plenty more)
> > >=================================================
>...
> > >- 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
> > 
> > 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. ;)
> 
> >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.

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%...

> 	Sam

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

Re: Kbuild update

[WANG Cong]

>> 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.

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

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

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

Re: Kbuild update

[Adrian Bunk]

On Sun, Jan 06, 2008 at 10:26:06PM +0800, WANG Cong wrote:
> 
> >> 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.
> 
> Well, I think it's worthy. The translation effort will be valuable
> and much helpful for non-English-speaking peoples.
> 
> >Besides the initial translation efforts a big problem would be to 
> >also find people who will regularly update the translations for
> >many years.
> 
> Yes, that's really a problem. But I think the updates won't be
> too frequent, only update for stable release is enough.

"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.

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

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...

> Regards.
> 
>  Cong

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

Re: Kbuild update

[Sam Ravnborg]

> 
> 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.

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

> 
> > If we can make this to be an offical project for Linux kernel, I
> > think it won't be a big problem.
> 
> 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.
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

Re: Kbuild update

[WANG Cong]

>> > If we can make this to be an offical project for Linux kernel, I
>> > think it won't be a big problem.
>> 
>> 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.
>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.
>

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

Re: Kbuild update

[Sam Ravnborg]

On Wed, Jan 09, 2008 at 10:32:39AM +0800, WANG Cong wrote:
> 
> >> > If we can make this to be an offical project for Linux kernel, I
> >> > think it won't be a big problem.
> >> 
> >> 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.
> >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.
> >
> 
> 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.

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

Re: Kbuild update

[WANG 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...

Hmm, yes.

>
>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.

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

>
>> If we can make this to be an offical project for Linux kernel, I
>> think it won't be a big problem.
>
>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...

Fully agreed.

Maybe we can restart TLKTP?

translations (Re: Kbuild update)

[Oleg Verych]

On Sun, Jan 06, 2008 at 10:26:06PM +0800, WANG Cong wrote:
> 
> >> 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.
> 
> Well, I think it's worthy. The translation effort will be valuable
> and much helpful for non-English-speaking peoples.
> 
> >
> >Besides the initial translation efforts a big problem would be to 
> >also find people who will regularly update the translations for
> >many years.
> >
> 
> 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.

"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.

> Regards.
> 
> 
>  Cong
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
_______

Re: translations (Re: Kbuild update)

[Sam Ravnborg]

> 
> 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.
$subject is purely about the kernel configuration - if that was not clear.

	Sam

Re: translations (Re: Kbuild update)

[WANG Cong]

>"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?

Perhaps yes.

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

>
>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.

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

Re: translations (Re: Kbuild update)

[Oleg Verych]

@ Wed, Jan 09, 2008 at 10:22:08AM +0800, WANG Cong wrote:
> 
> >"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?
> 
> Perhaps yes.
> 
> But at least now, that kind of translation still sucks. It can
> satisfy me.
> 
> >
> >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.
> 
> I never say to translate C comments. What we want to translate is the
> strings in Kconfig.

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.

> 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.

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).
____

Re: translations (Re: Kbuild update)

[WANG 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.

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 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.
>
>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.

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.


>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).

Translations can be put in .po files.

Thanks.

 Cong

kbuild update

[Sam Ravnborg]

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

Re: kbuild update

[Robert P. J. Day]

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*.  :-)

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: kbuild update

[Sam Ravnborg]

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.

	Sam

Re: kbuild update

[Robert P. J. Day]

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
========================================================================

Re: kbuild update

[Andrew Morton]

On Sun, 16 Sep 2007 08:58:03 -0400 (EDT) "Robert P. J. Day" <rpjday@mindspring.com> 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*.  :-)

box:/usr/src/linux-2.6.23-rc6> grep -r '^[      ]*#[    ]*define[       ]*CONFIG_' . | wc -l
415

bah.  They're all bugs - The CONFIG_foo namespace is (should be) reserved in
kernel coding.

Re: kbuild update

[Sam Ravnborg]

On Sun, Sep 16, 2007 at 12:23:43PM -0700, Andrew Morton wrote:
> On Sun, 16 Sep 2007 08:58:03 -0400 (EDT) "Robert P. J. Day" <rpjday@mindspring.com> 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*.  :-)
> 
> box:/usr/src/linux-2.6.23-rc6> grep -r '^[      ]*#[    ]*define[       ]*CONFIG_' . | wc -l
> 415
> 
> bah.  They're all bugs - The CONFIG_foo namespace is (should be) reserved in
> kernel coding.

I get (after a bit more filtering 349 hits of which 182 are outside drivers/

Of the 182 the 25 of them are in arch specific code.

I se no good reasons to address this unless we touch code in that area anyway.
But avoiding new entries are good.

	Sam

kbuild update

[Sam Ravnborg]

Short intro to content of kbuild.git at the moment.
See http://git.kernel.org/?p=linux/kernel/git/sam/kbuild.git;a=summary

Everything are targeted for next merge window.

section mismatch
      kbuild: make better section mismatch reports on i386, arm and mips
      kbuild: The .paravirtprobe section is obsolete, so modpost doesn't need to handle it
      kbuild: ignore section mismatch warnings originating from .note section
      kbuild: refactor code in modpost to improve maintainability
      kbuild: warn about references from .init.text to .exit.text
      kbuild: remove hardcoded apic_es7000 from modpost
      kbuild: refactor code in modpost
      kbuild: remove hardcoded _logo names from modpost
      kbuild: suppress modpost warnings for references from the .toc section as used by powerpc
      kbuild: whitelist references from variables named _timer to .init.text

Several changes to either improve reporting - or to ignore false positives.
In particular modpost now check for and warn about references from .init.text to .exit.text
This check caugth several real bugs - which for the most part are already fixed in upstream.
modpost now does a better job finding the symbols using addend - this works for me
but had caused troubles in the past. If modpost suddenly bails out with a segmentation
violation this may the the culprint.
In addition some trivial code refactoring was done to improve maintainability of modpost.


      kconfig: use POSIX equality test in check-lxdialog.sh
Bugfix.


      scripts: Make cleanfile/cleanpatch warn about long lines
Improved so we all adhere to 80 lines (in)sanity


      kbuild: avoid environment to set variables used by kbuild
I had a report that a user tried to do:
EXTRA_CFLAGS=FOO make fs/nfs/
This is not supposed to impact the build so make sure it does not.


      kbuild: add support for reading stdin with gen_init_cpio
      kbuild: add support for squashing uid/gid in gen_initramfs_list.sh
initramfs improvements


      kbuild: asm-offsets.h is now cleaned with O=.. builds
Bugfix


      kbuild: document cc-fullversion
      kbuild: New 'cc-fullversion' macro
      powerpc: Refuse to build 64-bit with GCC-4.2.0 and CONFIG_MODULES
Add and use cc-fullversion to obtain exact gcc version
See documentation in Documentation/kbuild/makefiles.txt


What's next?
-> davem has requested to add a new section used for code modifying support.
   The actual section name to use needs to be sorted out.
-> A few cygwin specific changes may hit kbuild - to allow the kernel to be built
   using cygwin on a windoze box.
-> A few trivial kconfig changes are pending. Needs to review them before they are ready.
-> A speed-up of headers_check is in the works. Got stalled but will look into it soon.
   The check goes down to ~3 sec on my not-so-fast machine
-> If I get really bored I may start a 'cleaning up all vmlinux.lds files' round.
   If someone would help out here it would be appreciated.
   These change will then be merged via the arch-maintaines and not really kbuild stuff..

	Sam

Re: kbuild update

[Sam Ravnborg]

Hmm, the patch serie should have been chained.

	Sam