-mcpu strikes back

-mcpu strikes back

[Alexey Dobriyan]

The change below is shitting i386 defconfig (as well as my usual config)
build log with warnings:

  CC      init/main.o
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

gcc is 4.1.1.

------------------
$ git-cat-file commit 5de043f4bd11a9e0a3e8daec7d1905da575a76b7
tree 1cdafacd6a0f6e12bd5b88d9031a6130169ca868
parent f6112ec27a8f0eee6c5a996f65c7bfd9457d9f85
author Oleg Verych <olecom@flower.upol.cz> 1170724701 +0100
committer Linus Torvalds <torvalds@woody.linux-foundation.org>
1170801049 -0800

[PATCH] kbuild: improve option checking, Kbuild.include cleanup

 GNU binutils, root users, tmpfiles, external modules ro builds must
 be fixed to do the right thing now.

Re: -mcpu strikes back

[Roman Zippel]

Hi,

On Wed, 7 Feb 2007, Alexey Dobriyan wrote:

> The change below is shitting i386 defconfig (as well as my usual config)
> build log with warnings:
> 
>   CC      init/main.o
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> 
> gcc is 4.1.1.
> 
> ------------------
> $ git-cat-file commit 5de043f4bd11a9e0a3e8daec7d1905da575a76b7
> tree 1cdafacd6a0f6e12bd5b88d9031a6130169ca868
> parent f6112ec27a8f0eee6c5a996f65c7bfd9457d9f85
> author Oleg Verych <olecom@flower.upol.cz> 1170724701 +0100
> committer Linus Torvalds <torvalds@woody.linux-foundation.org>
> 1170801049 -0800
> 
> [PATCH] kbuild: improve option checking, Kbuild.include cleanup
> 
>  GNU binutils, root users, tmpfiles, external modules ro builds must
>  be fixed to do the right thing now.

Linus, please revert. Thanks.

bye, Roman

[patch, fix build regression] kbuild: Kbuild.include avoid using spaces in call arguments

[Oleg Verych]

On Wed, Feb 07, 2007 at 06:47:15PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Wed, 7 Feb 2007, Alexey Dobriyan wrote:
> 
> > The change below is shitting i386 defconfig (as well as my usual config)
> > build log with warnings:
> > 
> >   CC      init/main.o
> > `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> > `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> > 
> > gcc is 4.1.1.
> > 
> > ------------------
> > $ git-cat-file commit 5de043f4bd11a9e0a3e8daec7d1905da575a76b7
> > tree 1cdafacd6a0f6e12bd5b88d9031a6130169ca868
> > parent f6112ec27a8f0eee6c5a996f65c7bfd9457d9f85
> > author Oleg Verych <olecom@flower.upol.cz> 1170724701 +0100
> > committer Linus Torvalds <torvalds@woody.linux-foundation.org>
> > 1170801049 -0800
> > 
> > [PATCH] kbuild: improve option checking, Kbuild.include cleanup
> > 
> >  GNU binutils, root users, tmpfiles, external modules ro builds must
> >  be fixed to do the right thing now.
> 
> Linus, please revert. Thanks.
 
Roman, while it went so fast to Linus, i didn't expect that, let me
try to fix all this with this little patch.

---
Subject: [patch] kbuild, Kbuild.include: avoid using spaces in call arguments

  Do not use whitespace in arguments of functions in makefiles, as
  they propagate further without notice. Thus we get

  + echo ' y'

  instead of

  + echo y

  Fix misleading comments.

Signed-off-by: Oleg Verych <olecom@flower.upol.cz>
---

 Whitespaces in makefiles are PITA. But i've learnt this already.

 scripts/Kbuild.include |   40 ++++++++++++++++++++--------------------
 1 file changed, 20 insertions(+), 20 deletions(-)

Index: linux-2.6.20/scripts/Kbuild.include
===================================================================
--- linux-2.6.20.orig/scripts/Kbuild.include	2007-02-07 22:54:01.814467250 +0100
+++ linux-2.6.20/scripts/Kbuild.include	2007-02-07 22:54:17.099422500 +0100
@@ -58,5 +58,5 @@ endef
 
 # checker-shell
-# Usage: option = $(call checker-shell, $(CC)...-o $$OUT, option-ok, otherwise)
+# Usage: option = $(call checker-shell,$(CC)...-o $$OUT,option-ok,otherwise)
 # Exit code chooses option. $$OUT is safe location for needless output.
 define checker-shell
@@ -75,21 +75,21 @@ endef
 
 # as-option
-# Usage: cflags-y += $(call as-option, -Wa$(comma)-isa=foo,)
-as-option = $(call checker-shell, \
-   $(CC) $(CFLAGS) $(1) -c -xassembler /dev/null -o $$OUT, $(1), $(2))
+# Usage: cflags-y += $(call as-option,-Wa$(comma)-isa=foo,)
+as-option = $(call checker-shell,\
+   $(CC) $(CFLAGS) $(1) -c -xassembler /dev/null -o $$OUT,$(1),$(2))
 
 # as-instr
-# Usage: cflags-y += $(call as-instr, instr, option1, option2)
-as-instr = $(call checker-shell, \
-   printf "$(1)" | $(CC) $(AFLAGS) -c -xassembler -o $$OUT -, $(2), $(3))
+# Usage: cflags-y += $(call as-instr,instr,option1,option2)
+as-instr = $(call checker-shell,\
+   printf "$(1)" | $(CC) $(AFLAGS) -c -xassembler -o $$OUT -,$(2),$(3))
 
 # cc-option
-# Usage: cflags-y += $(call cc-option, -march=winchip-c6, -march=i586)
-cc-option = $(call checker-shell, \
-   $(CC) $(CFLAGS) $(if $(3),$(3),$(1)) -S -xc /dev/null -o $$OUT, $(1), $(2))
+# Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586)
+cc-option = $(call checker-shell,\
+   $(CC) $(CFLAGS) $(if $(3),$(3),$(1)) -S -xc /dev/null -o $$OUT,$(1),$(2))
 
 # cc-option-yn
-# Usage: flag := $(call cc-option-yn, -march=winchip-c6)
-cc-option-yn = $(call cc-option, "y", "n", $(1))
+# Usage: flag := $(call cc-option-yn,-march=winchip-c6)
+cc-option-yn = $(call cc-option,"y","n",$(1))
 
 # cc-option-align
@@ -99,5 +99,5 @@ cc-option-align = $(subst -functions=0,,
 
 # cc-version
-# Usage gcc-ver := $(call cc-version, $(CC))
+# Usage gcc-ver := $(call cc-version,$(CC))
 cc-version = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
 
@@ -108,6 +108,6 @@ cc-ifversion = $(shell [ $(call cc-versi
 # ld-option
 # Usage: ldflags += $(call ld-option, -Wl$(comma)--hash-style=both)
-ld-option = $(call checker-shell, \
-   $(CC) $(1) -nostdlib -xc /dev/null -o $$OUT, $(1), $(2))
+ld-option = $(call checker-shell,\
+   $(CC) $(1) -nostdlib -xc /dev/null -o $$OUT,$(1),$(2))
 
 ######
@@ -121,13 +121,13 @@ build := -f $(if $(KBUILD_SRC),$(srctree
 # add original to the end
 addtree = $(if \
-	$(filter-out -I/%, $(1)), $(patsubst -I%,-I$(srctree)/%,$(1))) $(1)
+	$(filter-out -I/%,$(1)),$(patsubst -I%,-I$(srctree)/%,$(1))) $(1)
 
 # Find all -I options and call addtree
-flags = $(foreach o,$($(1)), \
-	$(if $(filter -I%,$(o)), $(call addtree, $(o)), $(o)))
+flags = $(foreach o,$($(1)),\
+	$(if $(filter -I%,$(o)),$(call addtree,$(o)),$(o)))
 
 # echo command.
 # Short version is used, if $(quiet) equals `quiet_', otherwise full one.
-echo-cmd = $(if $($(quiet)cmd_$(1)), \
+echo-cmd = $(if $($(quiet)cmd_$(1)),\
 	echo '  $(call escsq,$($(quiet)cmd_$(1)))$(echo-why)';)
 
@@ -136,5 +136,5 @@ cmd = @$(echo-cmd) $(cmd_$(1))
 
 # Add $(obj)/ for paths that are not absolute
-objectify = $(foreach o,$(1), $(if $(filter /%,$(o)), $(o), $(obj)/$(o)))
+objectify = $(foreach o,$(1),$(if $(filter /%,$(o)),$(o),$(obj)/$(o)))
 
 ###

Re: [patch, fix build regression] kbuild: Kbuild.include avoid using spaces in call arguments

[Roman Zippel]

Hi,

On Wed, 7 Feb 2007, Oleg Verych wrote:

> > Linus, please revert. Thanks.
>  
> Roman, while it went so fast to Linus, i didn't expect that, let me
> try to fix all this with this little patch.

Sorry, it needs more changes, the patch simply wasn't ready.

bye, Roman

Re: [patch, fix build regression] kbuild: Kbuild.include avoid using spaces in call arguments

[Randy Dunlap]

On Thu, 8 Feb 2007 00:34:50 +0100 (CET) Roman Zippel wrote:

> Hi,
> 
> On Wed, 7 Feb 2007, Oleg Verych wrote:
> 
> > > Linus, please revert. Thanks.
> >  
> > Roman, while it went so fast to Linus, i didn't expect that, let me
> > try to fix all this with this little patch.
> 
> Sorry, it needs more changes, the patch simply wasn't ready.

Can you be more explicit?  and then it should get some time
in -mm, hopefully.

Thanks,
---
~Randy

Re: [patch, fix build regression] kbuild: Kbuild.include avoid using spaces in call arguments

[Roman Zippel]

Hi,

On Wed, 7 Feb 2007, Randy Dunlap wrote:

> > > > Linus, please revert. Thanks.
> > >  
> > > Roman, while it went so fast to Linus, i didn't expect that, let me
> > > try to fix all this with this little patch.
> > 
> > Sorry, it needs more changes, the patch simply wasn't ready.
> 
> Can you be more explicit?  and then it should get some time
> in -mm, hopefully.

I did already. It needs to be splitted, lose the symlink stuff and be more 
careful with whitespace. It probably could use a better name than 
checker-shell, e.g. autoconf calls this TRY_RUN, so something like this.

bye, Roman

discussion of Kbuild fixes (kbuild: Kbuild.include avoid using spaces in call arguments)

[Oleg Verych]

On Thu, Feb 08, 2007 at 01:00:44AM +0100, Roman Zippel wrote:
> Hi,
> 
> On Wed, 7 Feb 2007, Randy Dunlap wrote:
> 
> > > > > Linus, please revert. Thanks.
> > > >  
> > > > Roman, while it went so fast to Linus, i didn't expect that, let me
> > > > try to fix all this with this little patch.
> > > 
> > > Sorry, it needs more changes, the patch simply wasn't ready.
> > 
> > Can you be more explicit?  and then it should get some time
> > in -mm, hopefully.
> 
> I did already. It needs to be splitted,

i did that patch for ultrasonic testers of Linus's tree. Shame on me,
because, i was sure, that... whatever. This is where i thought, that i
almost understand it all, but another huge level of complexity was
revealed (even it's just a whitespace ;).

I've started to split changes,

> lose the symlink stuff and be more careful with whitespace. It probably
> could use a better name than checker-shell, e.g. autoconf calls this
> TRY_RUN, so something like this.

but i can't understand you, Roman, against:

-- `find | sort' in localversion (i insist on split between paths and
    files)

-- symlinks to /dev/null in option checking -- isn't it better to not
   have any (though cached) access to files on filesystem, instead of to
   /dev/null? cont.:
 
Anyway, i think, it's better than before, that now all is one place, and
can be named as you wish. Any further changes, like common `tmp'
directory are easy to fix. Readable form, easy to test/debug:

add `-x' to `set' or `echo >gcc-checks.txt', and you will get output, you wish.

IMHO it's good, while arch specific gcc checking already done (:

I wish to have more people to work on this (even with just comments),
because "Kbuild.include" was only first step to reduce bloated top
Makefile. Since then, it seems, Sam have more important things to do.

If further work is useful, i will be glad if you think so.

Thanks.
____

Re: discussion of Kbuild fixes (kbuild: Kbuild.include avoid using spaces in call arguments)

[Roman Zippel]

Hi,

On Thu, 8 Feb 2007, Oleg Verych wrote:

> -- `find | sort' in localversion (i insist on split between paths and
>     files)

make has dedicated functions for this.

> -- symlinks to /dev/null in option checking -- isn't it better to not
>    have any (though cached) access to files on filesystem, instead of to
>    /dev/null? cont.:

symlinks are not much else than special files.

> I wish to have more people to work on this (even with just comments),
> because "Kbuild.include" was only first step to reduce bloated top
> Makefile. Since then, it seems, Sam have more important things to do.

The problem is that you mix multiple changes into a single patch, but 
since kbuild is very central part that puts everything together, I don't 
think it's bad idea to be more conservative, especially if you just start 
to work on it.

bye, Roman

Re: discussion of Kbuild fixes (kbuild: Kbuild.include avoid using spaces in call arguments)

[Oleg Verych]

On Thu, Feb 08, 2007 at 03:05:41AM +0100, Roman Zippel wrote:
> Hi,
> 
> On Thu, 8 Feb 2007, Oleg Verych wrote:
> 
> > -- `find | sort' in localversion (i insist on split between paths and
> >     files)
> 
> make has dedicated functions for this.

I think, "make" (even whatever shiny new) that particular problem can't
handle. Regexp on *file name* is needed, while PATH must be untouched.
That what i meant with spliting tasks. Stripping strings of wildcards
by "make dedicated functions" is ugly, IMHO. 

Also, what do you think, if someone (very unlikely) will add port of build
system to something different? Clear logic for a "rule" is there, one can
easily make whole `include/config/kernel.release' with that.

> > -- symlinks to /dev/null in option checking -- isn't it better to not
> >    have any (though cached) access to files on filesystem, instead of to
> >    /dev/null? cont.:
> 
> symlinks are not much else than special files.

IMHO, cheap I/O. Yes, that isn't a big benefit, but i don't see anything
against, except, probably, filesystems without support of symlinks.

> > I wish to have more people to work on this (even with just comments),
> > because "Kbuild.include" was only first step to reduce bloated top
> > Makefile. Since then, it seems, Sam have more important things to do.
> 
> The problem is that you mix multiple changes into a single patch,

Yes, from whitespace-issue point of view, that was a huge change (:,

> but since kbuild is very central part that puts everything together,

and patch set didn't make a single release of -mm tree (:

> I don't think it's bad idea to be more conservative, especially if you
> just start to work on it.

.... alone. I think it will be OK, Linus is with us!


Thanks, Roman.

____

Re: [patch, fix build regression] kbuild: Kbuild.include avoid using spaces in call arguments

[Linus Torvalds]

On Thu, 8 Feb 2007, Roman Zippel wrote:
> 
> Sorry, it needs more changes, the patch simply wasn't ready.

One problem I find very problematic with all the Kbuild setup is that 
people tend to be very quiet about any build issues until they simply go 
in.

Things don't "get ready" on their own. In other areas, people comment on 
why they don't like patches. In Kbuild, for some reason, we often seem to 
have this situation where people don't react at all.

Sam is great about maintaining the kernel build stuff most of the time, 
but because it's clearly a "secondary" thing, there tends to be some 
periods when nothing happens. Which is problematic for me..

So I end up in a situation where I just basically will apply the patches 
just becauseif I don't, nothing ever happens. The good news is that _once_ 
I apply them, people will usually notice problems and send in fixes fairly 
quickly. But this particular email was NOT useful, for example.  "needs 
more changes" is the epitome of a "not useful" comment.

I notice that Kai should probably have been Cc'd, and quite possibly 
wasn't. So I added him now.

In the meantime, I've applied the fixup patch. And more specific problem 
reports or patches are welcome.

		Linus

Re: [patch, fix build regression] kbuild: Kbuild.include avoid using spaces in call arguments

[Roman Zippel]

Hi,

On Wed, 7 Feb 2007, Linus Torvalds wrote:

> So I end up in a situation where I just basically will apply the patches 
> just becauseif I don't, nothing ever happens. The good news is that _once_ 
> I apply them, people will usually notice problems and send in fixes fairly 
> quickly. But this particular email was NOT useful, for example.  "needs 
> more changes" is the epitome of a "not useful" comment.

The patch was already in -mm and being worked on...

> In the meantime, I've applied the fixup patch. And more specific problem 
> reports or patches are welcome.

_Please_ revert completely and wait for Andrew to send it via -mm, when 
it's ready.

bye, Roman

Re: [patch, fix build regression] kbuild: Kbuild.include avoid using spaces in call arguments

[Andrew Morton]

On Wed, 7 Feb 2007 15:52:54 -0800 (PST) Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, 8 Feb 2007, Roman Zippel wrote:
> > 
> > Sorry, it needs more changes, the patch simply wasn't ready.
> 
> One problem I find very problematic with all the Kbuild setup is that 
> people tend to be very quiet about any build issues until they simply go 
> in.
> 
> Things don't "get ready" on their own. In other areas, people comment on 
> why they don't like patches. In Kbuild, for some reason, we often seem to 
> have this situation where people don't react at all.
> 
> Sam is great about maintaining the kernel build stuff most of the time, 
> but because it's clearly a "secondary" thing, there tends to be some 
> periods when nothing happens. Which is problematic for me..
> 
> So I end up in a situation where I just basically will apply the patches 
> just becauseif I don't, nothing ever happens. The good news is that _once_ 
> I apply them, people will usually notice problems and send in fixes fairly 
> quickly. But this particular email was NOT useful, for example.  "needs 
> more changes" is the epitome of a "not useful" comment.

Yes, kbuild is a bit of a problem at present.

I'm sitting on these:

search-a-little-harder-for-mkimage.patch
make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
add-mailmap-for-proper-git-shortlog-output.patch
qconf-immediately-update-integer-and-string-values-in-xconfig-display-take-2.patch
qconf-relocate-search-command.patch
qconf-fix-showing-help-info-on-failed-search.patch
qconf-back-button-behaviour-normalization.patch
kbuild-remove-references-to-deprecated-prepare-all-target.patch
new-toplevel-target-headers_check_all.patch

But I'm not sure that anyone has reviewed them much.

I'll probably just push 'em and see what happens.  They seem to work.

dd

[Oleg Verych]

Hallo.

search-a-little-harder-for-mkimage.patch

------------------------------------------------------
Subject: search a little harder for mkimage
From: "Mike Frysinger" <vapier.adi@gmail.com>

> Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> the standard `mkimage`

Why this can't be done by

  PATH=$CROSS_COMPILE:$PATH

in your environment?

> The Blackfin toolchain includes mkimage, but we dont want to namespace
> collide with any of the user's system setup, so we prefix it with our
> toolchain name.

If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
with "dash" (very good `sh' equivalents) will fail. I would recomend to
use "which" command (btw, Debian has `sh' version of it), if you
concerned about size and performance.

Nack + proposition to move from `bash' to `sh'.

-MKIMAGE=$(type -path mkimage)
+MKIMAGE=$(type -path ${CROSS_COMPILE}mkimage)
 
 if [ -z "${MKIMAGE}" ]; then
-	# Doesn't exist
-	echo '"mkimage" command not found - U-Boot images will not be built' >&2
-	exit 0;
+	MKIMAGE=$(type -path mkimage)
+	if [ -z "${MKIMAGE}" ]; then
+		# Doesn't exist
+		echo '"mkimage" command not found - U-Boot images will not be built' >&2
+		exit 0;
+	fi
 fi

____

Re: dd

[Andrew Morton]

On Thu, 8 Feb 2007 06:24:40 +0100 Oleg Verych <olecom@flower.upol.cz> wrote:

> If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> with "dash" (very good `sh' equivalents) will fail.

Does the kernel presently build with that shell?

Re: + search-a-little-harder-for-mkimage.patch

[Oleg Verych]

On Wed, Feb 07, 2007 at 09:19:21PM -0800, Andrew Morton wrote:
> On Thu, 8 Feb 2007 06:24:40 +0100 Oleg Verych <olecom@flower.upol.cz> wrote:
> 
> > If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> > with "dash" (very good `sh' equivalents) will fail.
> 
> Does the kernel presently build with that shell?

build - yes, with dash being `$(shell)'. All scripts with `#!/bin/bash'
of course use bash, example is gen_initramfs_list.sh.

Trivial shell scripts, especially for embedded archs (Blackfin is
one, IIRC), may be easily converted.

BTW, Debian shell policy is to be bashizms-clear. Purpose -- to have
compatibility with any `sh'. Shall we?

____

Re: + search-a-little-harder-for-mkimage.patch

[Mike Frysinger]

On 2/8/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> On Wed, Feb 07, 2007 at 09:19:21PM -0800, Andrew Morton wrote:
> > On Thu, 8 Feb 2007 06:24:40 +0100 Oleg Verych <olecom@flower.upol.cz> wrote:
> >
> > > If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> > > with "dash" (very good `sh' equivalents) will fail.
> >
> > Does the kernel presently build with that shell?
>
> build - yes, with dash being `$(shell)'. All scripts with `#!/bin/bash'
> of course use bash, example is gen_initramfs_list.sh.

which is what mkuboot.sh is using now

> Trivial shell scripts, especially for embedded archs (Blackfin is
> one, IIRC), may be easily converted.

yes, but Blackfin is no-mmu so converting the script to use POSIX
shell is pointless to us since no-mmu is not a self-hosting
environment
-mike

Re: + search-a-little-harder-for-mkimage.patch

[Oleg Verych]

On Thu, Feb 08, 2007 at 12:58:26AM -0500, Mike Frysinger wrote:
> On 2/8/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> >On Wed, Feb 07, 2007 at 09:19:21PM -0800, Andrew Morton wrote:
> >> On Thu, 8 Feb 2007 06:24:40 +0100 Oleg Verych <olecom@flower.upol.cz> 
> >wrote:
> >>
> >> > If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> >> > with "dash" (very good `sh' equivalents) will fail.
> >>
> >> Does the kernel presently build with that shell?
> >
> >build - yes, with dash being `$(shell)'. All scripts with `#!/bin/bash'
> >of course use bash, example is gen_initramfs_list.sh.
> 
> which is what mkuboot.sh is using now
> 
> >Trivial shell scripts, especially for embedded archs (Blackfin is
> >one, IIRC), may be easily converted.
> 
> yes, but Blackfin is no-mmu so converting the script to use POSIX
> shell is pointless to us since no-mmu is not a self-hosting
> environment

Heh, did i say POSIX? I said bloated shell, from man bash:

BUGS
       It's too big and too slow.


____

Re: + search-a-little-harder-for-mkimage.patch

[Mike Frysinger]

On 2/8/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> On Thu, Feb 08, 2007 at 12:58:26AM -0500, Mike Frysinger wrote:
> > On 2/8/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> > >Trivial shell scripts, especially for embedded archs (Blackfin is
> > >one, IIRC), may be easily converted.
> >
> > yes, but Blackfin is no-mmu so converting the script to use POSIX
> > shell is pointless to us since no-mmu is not a self-hosting
> > environment
>
> Heh, did i say POSIX?

/bin/sh is the POSIX shell ... if you want to switch off of /bin/bash,
then the only other sane option is /bin/sh which means rewriting the
code to be POSIX compliant

> I said bloated shell, from man bash:
>
> BUGS
>        It's too big and too slow.

we get it, you dont like bash, why do you feel the need to keep making
these statements ?
-mike

Re: + search-a-little-harder-for-mkimage.patch

[Jan Engelhardt]

On Feb 8 2007 07:43, Oleg Verych wrote:
>> >>
>> >> > If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
>> >> > with "dash" (very good `sh' equivalents) will fail.
>> >>
>> >> Does the kernel presently build with that shell?
>> >
>> >build - yes, with dash being `$(shell)'. All scripts with `#!/bin/bash'
>> >of course use bash, example is gen_initramfs_list.sh.
>> 
>
>Heh, did i say POSIX? I said bloated shell, from man bash:
>
>BUGS
>       It's too big and too slow.

Like it or lump it. Improve it, or write your own bash-compliant sh. :)

Re: + search-a-little-harder-for-mkimage.patch

[Roman Zippel]

Hi,

On Thu, 8 Feb 2007, Oleg Verych wrote:

> BTW, Debian shell policy is to be bashizms-clear. Purpose -- to have
> compatibility with any `sh'. Shall we?

Wrong.

http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts

bye, Roman

Re: + search-a-little-harder-for-mkimage.patch

[Oleg Verych]

On Thu, Feb 08, 2007 at 05:38:28PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Thu, 8 Feb 2007, Oleg Verych wrote:
> 
> > BTW, Debian shell policy is to be bashizms-clear. Purpose -- to have
> > compatibility with any `sh'. Shall we?
> 
> Wrong.
> 
> http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
"""
   You may wish to restrict your script to POSIX features when possible
   so that it may use /bin/sh as its interpreter. If your script works
   with dash (originally called ash), it's probably POSIX compliant, but
   if you are in doubt, use /bin/bash.
"""
I think, it's OK to start with ;)      

> bye, Roman

____

Re: dd

[Mike Frysinger]

On 2/8/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> > Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> > the standard `mkimage`
>
> Why this can't be done by
>
>   PATH=$CROSS_COMPILE:$PATH
>
> in your environment?

because it wouldnt matter ?  the tool is called
"$CROSS_COMPILE-mkimage", it isnt $CROSS_COMPILE_PATH/mkimage

> > The Blackfin toolchain includes mkimage, but we dont want to namespace
> > collide with any of the user's system setup, so we prefix it with our
> > toolchain name.
>
> If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> with "dash" (very good `sh' equivalents) will fail. I would recomend to
> use "which" command (btw, Debian has `sh' version of it), if you
> concerned about size and performance.
>
> Nack + proposition to move from `bash' to `sh'.

the script already uses "#!/bin/bash" and the patch doesnt change any
of the existing conventions ... so if you want to rewrite the existing
code to be POSIX compliant, then do so so i can add back in support
for $CROSS_COMPILE-mkimage
-mike

Re: search-a-little-harder-for-mkimage.patch

[Oleg Verych]

On Thu, Feb 08, 2007 at 12:56:17AM -0500, Mike Frysinger wrote:
> On 2/8/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> >> Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> >> the standard `mkimage`
> >
> >Why this can't be done by
> >
> >  PATH=$CROSS_COMPILE:$PATH
> >
> >in your environment?
> 
> because it wouldnt matter ?  the tool is called
> "$CROSS_COMPILE-mkimage", it isnt $CROSS_COMPILE_PATH/mkimage

Well, i mean search for your `mkimage'.

Let's see how all this used in Makefiles (avr32, ppc, sh are same)

../arch/arm/boot/Makefile:

   MKIMAGE         := $(srctree)/scripts/mkuboot.sh
   ...
   quiet_cmd_uimage = UIMAGE  $@
         cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
                   -C none -a $(ZRELADDR) -e $(ZRELADDR) \
                   -n 'Linux-$(KERNELRELEASE)' -d $< $@

type, which with bash or whatever, doesn't matter. All they need *your*
toolchain in $PATH, why not just to put "$CROSS_COMPILE-mkimage" instead
of $(CONFIG_SHELL) $(MKIMAGE) here? mkuboot.sh just searches $PATH for
mkimage and run it. Double overkill, no?

> >> The Blackfin toolchain includes mkimage, but we dont want to namespace
> >> collide with any of the user's system setup, so we prefix it with our
> >> toolchain name.
> >
> >If that matter, `type -path' is bashizm (BloAted SHell), and "blackbox"
> >with "dash" (very good `sh' equivalents) will fail. I would recomend to
> >use "which" command (btw, Debian has `sh' version of it), if you
> >concerned about size and performance.
> >
> >Nack + proposition to move from `bash' to `sh'.
> 
> the script already uses "#!/bin/bash" and the patch doesnt change any
> of the existing conventions ... so if you want to rewrite the existing
> code to be POSIX compliant, then do so so i can add back in support
> for $CROSS_COMPILE-mkimage

To run faster, but let me stop here.
____

Re: search-a-little-harder-for-mkimage.patch

[Mike Frysinger]

On 2/8/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> On Thu, Feb 08, 2007 at 12:56:17AM -0500, Mike Frysinger wrote:
> > On 2/8/07, Oleg Verych <olecom@flower.upol.cz> wrote:
> > >> Check to see if `${CROSS_COMPILE}mkimage` exists and if not, fall back to
> > >> the standard `mkimage`
> > >
> > >Why this can't be done by
> > >
> > >  PATH=$CROSS_COMPILE:$PATH
> > >
> > >in your environment?
> >
> > because it wouldnt matter ?  the tool is called
> > "$CROSS_COMPILE-mkimage", it isnt $CROSS_COMPILE_PATH/mkimage
>
> Well, i mean search for your `mkimage'.
>
> Let's see how all this used in Makefiles (avr32, ppc, sh are same)
>
> ../arch/arm/boot/Makefile:
>
>    MKIMAGE         := $(srctree)/scripts/mkuboot.sh
>    ...
>    quiet_cmd_uimage = UIMAGE  $@
>          cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
>                    -C none -a $(ZRELADDR) -e $(ZRELADDR) \
>                    -n 'Linux-$(KERNELRELEASE)' -d $< $@
>
> type, which with bash or whatever, doesn't matter. All they need *your*
> toolchain in $PATH, why not just to put "$CROSS_COMPILE-mkimage" instead
> of $(CONFIG_SHELL) $(MKIMAGE) here? mkuboot.sh just searches $PATH for
> mkimage and run it. Double overkill, no?

by this argument, why does mkuboot.sh exist at all then ?  let's
simply delete mkuboot.sh and change all arch Makefile's like so:
-    $(CONFIG_SHELL) $(MKIMAGE) ...
+    -mkimage ...

i of course prefer the existing solution: call the mkuboot.sh script
which checks for a few variations of the `mkimage` binary and if it
does not exist, output a friendly message
-mike

Re: search-a-little-harder-for-mkimage.patch

[Oleg Verych]

On Thu, Feb 08, 2007 at 02:40:28AM -0500, Mike Frysinger wrote:
[] 
> by this argument, why does mkuboot.sh exist at all then ?  let's
> simply delete mkuboot.sh and change all arch Makefile's like so:
> -    $(CONFIG_SHELL) $(MKIMAGE) ...
> +    -mkimage ...

Yes (with TOOLCHAIN prefix).

> i of course prefer the existing solution: call the mkuboot.sh script
> which checks for a few variations of the `mkimage` binary and if it
> does not exist, output a friendly message

so as `make' will, but better than patched "friendly message", which
doesn't reflect: neither change to toolchain prefix, nor possible
permission problems, or what ever it can be, preventing actual running
the command ;)

____

+ make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch

[Oleg Verych]

> make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
[]
> Fix a minor bug in mkcompile_h.  As one can see, the current locale is used
> while getting the version of gcc.  This produces problems when a locale
> other than C or en_US is used.  As an example, my /proc/version contains
> Turkish characters in iso-8859-9 encoding.
>
> This patch fixes this issue by making sure that the C locale is used to get
> gcc's version.

Files in C must be in ASCII. Thus, my proposition is to
"export LC_ALL=C LANG=C" first, and remove any all other "LC_ALL=C
LANG=C", to have "compile.h" in it.


@@ -58,7 +58,7 @@ UTS_TRUNCATE="sed -e s/\(.\{1,$UTS_LEN\}
     echo \#define LINUX_COMPILE_DOMAIN
   fi
 
-  echo \#define LINUX_COMPILER \"`$CC -v 2>&1 | tail -n 1`\"
+  echo \#define LINUX_COMPILER \"`LC_ALL=C LANG=C $CC -v 2>&1 | tail -n 1`\"
 ) > .tmpcompile
 
 # Only replace the real compile.h if the new one is different,
_

Patches currently in -mm which might be from situert@yahoo.com are

make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch

Re: [patch, fix build regression] kbuild: Kbuild.include avoid using spaces in call arguments

[Roman Zippel]

Hi,

On Wed, 7 Feb 2007, Andrew Morton wrote:

> I'm sitting on these:
> 
> search-a-little-harder-for-mkimage.patch
> make-mkcompile_h-use-lang=c-and-lc_all=c-for-cc-v.patch
> add-mailmap-for-proper-git-shortlog-output.patch
> qconf-immediately-update-integer-and-string-values-in-xconfig-display-take-2.patch
> qconf-relocate-search-command.patch
> qconf-fix-showing-help-info-on-failed-search.patch
> qconf-back-button-behaviour-normalization.patch
> kbuild-remove-references-to-deprecated-prepare-all-target.patch
> new-toplevel-target-headers_check_all.patch
> 
> But I'm not sure that anyone has reviewed them much.

Patches look fine and most of the kconfig related patches are already the 
result of a review.

bye, Roman

.mailmap in top directory

[Oleg Verych]

On Wed, Feb 07, 2007 at 10:42:27PM -0800, Andrew Morton wrote:
[]
> > > add-mailmap-for-proper-git-shortlog-output.patch
> > 
> > i can't tell anything about this one. For what?
> 
> Beats me.  git stuff.  I'll let Linus decide.

So it's in 2.6.21-rc1.

Is it really so necessary in the linux-source?
Who suppose to track and update this?

____

Re: [patch, fix build regression] kbuild: Kbuild.include avoid using spaces in call arguments

[Sam Ravnborg]

On Wed, Feb 07, 2007 at 03:52:54PM -0800, Linus Torvalds wrote:
> 
> 
> On Thu, 8 Feb 2007, Roman Zippel wrote:
> > 
> > Sorry, it needs more changes, the patch simply wasn't ready.
> 
> One problem I find very problematic with all the Kbuild setup is that 
> people tend to be very quiet about any build issues until they simply go 
> in.
> 
> Things don't "get ready" on their own. In other areas, people comment on 
> why they don't like patches. In Kbuild, for some reason, we often seem to 
> have this situation where people don't react at all.
> 
> Sam is great about maintaining the kernel build stuff most of the time, 
> but because it's clearly a "secondary" thing, there tends to be some 
> periods when nothing happens. Which is problematic for me..
Sorry about my silence for now three months.
Been overly busy and with family now extended to three kids takes time too.

I will be back in a months time - maybe a bit sooner.
As for the Kbuild area I usual have patches cooking in -mm for a while
before pushing to you - comments are usual few when I post patches
which I take as a sign that most people do not care about Kbuild
as long as it works, other are not into the makefile trickery,
and also that the patches are small logical steps (which is
true for all contributions and not just mine).

	Sam