[PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
From: Rob Landley
Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell script
is much simpler, about 1/4 the size, and runs on Red Hat 9 from 2003.
Peter Anvin added this perl to 2.6.25. Before that, the kernel had never
required perl to build.
Signed-off-by: Rob Landley
---
kernel/Makefile |4
kernel/timeconst.pl | 378 --
kernel/timeconst.sh | 91 ++
3 files changed, 93 insertions(+), 380 deletions(-)
diff -r d0c7611dcfd6 kernel/Makefile
--- a/kernel/Makefile Tue Dec 30 17:48:25 2008 -0800
+++ b/kernel/Makefile Fri Jan 02 00:10:44 2009 -0600
@@ -115,7 +115,7 @@
$(obj)/time.o: $(obj)/timeconst.h
quiet_cmd_timeconst = TIMEC $@
- cmd_timeconst = $(PERL) $< $(CONFIG_HZ) > $@
+ cmd_timeconst = $(CONFIG_SHELL) $< $(CONFIG_HZ) > $@
targets += timeconst.h
-$(obj)/timeconst.h: $(src)/timeconst.pl FORCE
+$(obj)/timeconst.h: $(src)/timeconst.sh FORCE
$(call if_changed,timeconst)
--- /dev/null 1969-12-31 00:00:00.0 -0600
+++ hg/kernel/timeconst.sh 2009-01-01 23:53:17.0 -0600
@@ -0,0 +1,91 @@
+#!/bin/bash
+
+if [ $# -ne 1 ]
+then
+ echo "Usage: timeconst.sh HZ"
+ exit 1
+fi
+
+HZ=$1
+
+# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit math.
+
+[ $((1<<32)) -lt 0 ] && exit 1
+
+# Output start of header file
+
+cat << EOF
+/* Automatically generated by kernel/timeconst.sh */
+/* Conversion constants for HZ == $HZ */
+
+#ifndef KERNEL_TIMECONST_H
+#define KERNEL_TIMECONST_H
+
+#include
+#include
+
+#if HZ != $HZ
+#error "kernel/timeconst.h has the wrong HZ value!"
+#endif
+
+EOF
+
+# For both Miliseconds and Microseconds
+
+for i in "MSEC 1000" "USEC 100"
+do
+ NAME=$(echo $i | awk '{print $1}')
+ PERIOD=$(echo $i | awk '{print $2}')
+
+ # Find greatest common denominator (using Euclid's algorithm)
+
+ A=$HZ
+ B=$PERIOD
+
+ while [ $B -ne 0 ]
+ do
+ C=$(($A%$B))
+ A=$B
+ B=$C
+ done
+
+ GCD=$A
+
+ # Do this for each direction (HZ_TO_PERIOD and PERIOD_TO_HZ)
+
+ for DIRECTION in 0 1
+ do
+ if [ $DIRECTION -eq 0 ]
+ then
+ CONVERT="HZ_TO_${NAME}"
+ FROM=$HZ
+ TO=$PERIOD
+ else
+ CONVERT="${NAME}_TO_HZ"
+ FROM=$PERIOD
+ TO=$HZ
+ fi
+
+ # How many shift bits give 32 bits of significant data?
+
+ SHIFT=0
+ while [ $(( (($TO<<$SHIFT)+$FROM-1)/$FROM )) -lt $((1<<31)) ]
+ do
+ SHIFT=$(( $SHIFT+1 ))
+ done
+
+ MUL32=$(( (($TO<<$SHIFT)+$FROM-1)/$FROM ))
+ MUL32=$(printf %x $MUL32)
+ echo "#define ${CONVERT}_MUL32 U64_C(0x$MUL32)"
+ ADJ32=$(($FROM/$GCD))
+ ADJ32=$(( (($ADJ32-1)<<$SHIFT)/$ADJ32 ))
+ ADJ32=$(printf %x $ADJ32)
+ echo "#define ${CONVERT}_ADJ32 U64_C(0x$ADJ32)"
+ echo "#define ${CONVERT}_SHR32 $SHIFT"
+ echo "#define ${CONVERT}_NUMU64_C($(($TO/$GCD)))"
+ echo "#define ${CONVERT}_DENU64_C($(($FROM/$GCD)))"
+ done
+done
+
+echo
+echo "#endif /* KERNEL_TIMECHONST_H */"
--- hg/kernel/timeconst.pl 2008-11-22 19:09:13.0 -0600
+++ /dev/null 1969-12-31 00:00:00.0 -0600
@@ -1,378 +0,0 @@
-#!/usr/bin/perl
-# ---
-#
-# Copyright 2007-2008 rPath, Inc. - All Rights Reserved
-#
-# This file is part of the Linux kernel, and is made available under
-# the terms of the GNU General Public License version 2 or (at your
-# option) any later version; incorporated herein by reference.
-#
-# ---
-#
-
-#
-# Usage: timeconst.pl HZ > timeconst.h
-#
-
-# Precomputed values for systems without Math::BigInt
-# Generated by:
-# timeconst.pl --can 24 32 48 64 100 122 128 200 250 256 300 512 1000 1024 1200
-%canned_values = (
- 24 => [
- '0xa6ab','0x2aa',26,
- 125,3,
- '0xc49ba5e4','0x1fbe76c8b4',37,
- 3,125,
- '0xa2c2aaab','0x',16,
- 125000,3,
- '0xc9539b89','0x7fffbce4217d',47,
- 3,125000,
- ], 32 => [
- '0xfa00','0x600',27,
- 125,4,
- '0x83126e98','0xfdf3b645a',36,
- 4,125,
- '0xf424','0x0',17,
- 31250,1,
- '0x8637bd06','0x3fff79c842fa',46,
- 1,31250,
- ], 48 => [
- '0xa6ab','0x6aa',27,
- 125,6,
- '0xc49ba5e4','0xfdf3b645a',36,
-
[PATCH 2/3]: Remove perl from make headers_install
From: Rob Landley
Remove perl from make headers_install by replacing a perl script (doing
a simple regex search and replace) with a smaller and faster shell script
implementation. The new shell script is a single for loop calling sed and
piping its output through unifdef to produce the target file.
Sam Ravnborg added this perl to 2.6.27.
Signed-off-by: Rob Landley
---
scripts/Makefile.headersinst |6 ++--
scripts/headers_install.pl | 46 -
scripts/headers_install.sh | 23
3 files changed, 26 insertions(+), 49 deletions(-)
--- /dev/null 2008-11-21 04:46:41.0 -0600
+++ b/scripts/headers_install.sh2008-12-15 22:09:45.0 -0600
@@ -0,0 +1,23 @@
+#!/bin/bash
+
+# Grab arguments
+
+INDIR="$1"
+shift
+OUTDIR="$1"
+shift
+ARCH="$1"
+shift
+
+# Iterate through files listed on command line
+
+for i in "$@"
+do
+ sed -r \
+ -e 's/([ \t(])(__user|__force|__iomem)[ \t]/\1/g' \
+ -e 's/__attribute_const__([ \t]|$)/\1/g' \
+ -e 's...@^#include @@' "$INDIR/$i" |
+ scripts/unifdef -U__KERNEL__ - > "$OUTDIR/$i"
+done
+
+exit 0
diff -r d9b501c91442 scripts/Makefile.headersinst
--- a/scripts/Makefile.headersinst Sun Dec 14 16:25:19 2008 -0800
+++ b/scripts/Makefile.headersinst Mon Dec 15 23:30:15 2008 -0600
@@ -44,8 +44,8 @@
quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\
file$(if $(word 2, $(all-files)),s))
cmd_install = \
-$(PERL) $< $(srctree)/$(obj) $(install) $(SRCARCH) $(header-y); \
-$(PERL) $< $(objtree)/$(obj) $(install) $(SRCARCH) $(objhdr-y); \
+ $(CONFIG_SHELL) $< $(srctree)/$(obj) $(install) $(SRCARCH)
$(header-y); \
+ $(CONFIG_SHELL) $< $(objtree)/$(obj) $(install) $(SRCARCH)
$(objhdr-y); \
touch $@
quiet_cmd_remove = REMOVE $(unwanted)
@@ -64,7 +64,7 @@
@:
targets += $(install-file)
-$(install-file): scripts/headers_install.pl $(input-files) FORCE
+$(install-file): scripts/headers_install.sh $(input-files) FORCE
$(if $(unwanted),$(call cmd,remove),)
$(if $(wildcard $(dir $@)),,$(shell mkdir -p $(dir $@)))
$(call if_changed,install)
--- hg/scripts/headers_install.pl 2008-11-22 19:09:21.0 -0600
+++ /dev/null 1970-01-01 00:00:00 -0600
@@ -1,46 +0,0 @@
-#!/usr/bin/perl -w
-#
-# headers_install prepare the listed header files for use in
-# user space and copy the files to their destination.
-#
-# Usage: headers_install.pl readdir installdir arch [files...]
-# readdir:dir to open files
-# installdir: dir to install the files
-# arch: current architecture
-# arch is used to force a reinstallation when the arch
-# changes because kbuild then detect a command line change.
-# files: list of files to check
-#
-# Step in preparation for users space:
-# 1) Drop all use of compiler.h definitions
-# 2) Drop include of compiler.h
-# 3) Drop all sections defined out by __KERNEL__ (using unifdef)
-
-use strict;
-
-my ($readdir, $installdir, $arch, @files) = @ARGV;
-
-my $unifdef = "scripts/unifdef -U__KERNEL__";
-
-foreach my $file (@files) {
- local *INFILE;
- local *OUTFILE;
- my $tmpfile = "$installdir/$file.tmp";
- open(INFILE, "<$readdir/$file")
- or die "$readdir/$file: $!\n";
- open(OUTFILE, ">$tmpfile") or die "$tmpfile: $!\n";
- while (my $line = ) {
- $line =~ s/([\s(])__user\s/$1/g;
- $line =~ s/([\s(])__force\s/$1/g;
- $line =~ s/([\s(])__iomem\s/$1/g;
- $line =~ s/\s__attribute_const__\s/ /g;
- $line =~ s/\s__attribute_const__$//g;
- $line =~ s/^#include //;
- printf OUTFILE "%s", $line;
- }
- close OUTFILE;
- close INFILE;
- system $unifdef . " $tmpfile > $installdir/$file";
- unlink $tmpfile;
-}
-exit 0;
[PATCH 3/3]: Convert mkcapflags.pl to mkcapflags.sh
From: Rob Landley
Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh.
This script generates kernel/cpu/capflags.c from include/asm/cpufeature.h.
Peter Anvin added this perl to 2.6.28.
Signed-off-by: Rob Landley
---
arch/x86/kernel/cpu/Makefile |4 +--
arch/x86/kernel/cpu/mkcapflags.pl | 32
arch/x86/kernel/cpu/mkcapflags.sh | 28
3 files changed, 30 insertions(+), 34 deletions(-)
diff -ruN alt-linux/arch/x86/kernel/cpu/Makefile
alt-linux2/arch/x86/kernel/cpu/Makefile
--- alt-linux/arch/x86/kernel/cpu/Makefile 2008-12-24 17:26:37.0
-0600
+++ alt-linux2/arch/x86/kernel/cpu/Makefile 2008-12-28 18:10:51.0
-0600
@@ -23,10 +23,10 @@
obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o
quiet_cmd_mkcapflags = MKCAP $@
- cmd_mkcapflags = $(PERL) $(srctree)/$(src)/mkcapflags.pl $< $@
+ cmd_mkcapflags = $(CONFIG_SHELL) $(srctree)/$(src)/mkcapflags.sh $< $@
cpufeature = $(src)/../../include/asm/cpufeature.h
targets += capflags.c
-$(obj)/capflags.c: $(cpufeature) $(src)/mkcapflags.pl FORCE
+$(obj)/capflags.c: $(cpufeature) $(src)/mkcapflags.sh FORCE
$(call if_changed,mkcapflags)
diff -ruN alt-linux/arch/x86/kernel/cpu/mkcapflags.pl
alt-linux2/arch/x86/kernel/cpu/mkcapflags.pl
--- alt-linux/arch/x86/kernel/cpu/mkcapflags.pl 2008-12-24 17:26:37.0
-0600
+++ alt-linux2/arch/x86/kernel/cpu/mkcapflags.pl1969-12-31
18:00:00.0 -0600
@@ -1,32 +0,0 @@
-#!/usr/bin/perl
-#
-# Generate the x86_cap_flags[] array from include/asm-x86/cpufeature.h
-#
-
-($in, $out) = @ARGV;
-
-open(IN, "< $in\0") or die "$0: cannot open: $in: $!\n";
-open(OUT, "> $out\0") or die "$0: cannot create: $out: $!\n";
-
-print OUT "#include \n\n";
-print OUT "const char * const x86_cap_flags[NCAPINTS*32] = {\n";
-
-while (defined($line = )) {
- if ($line =~ /^\s*\#\s*define\s+(X86_FEATURE_(\S+))\s+(.*)$/) {
- $macro = $1;
- $feature = $2;
- $tail = $3;
- if ($tail =~ /\/\*\s*\"([^"]*)\".*\*\//) {
- $feature = $1;
- }
-
- if ($feature ne '') {
- printf OUT "\t%-32s = \"%s\",\n",
- "[$macro]", "\L$feature";
- }
- }
-}
-print OUT "};\n";
-
-close(IN);
-close(OUT);
diff -ruN alt-linux/arch/x86/kernel/cpu/mkcapflags.sh
alt-linux2/arch/x86/kernel/cpu/mkcapflags.sh
--- alt-linux/arch/x86/kernel/cpu/mkcapflags.sh 1969-12-31 18:00:00.0
-0600
+++ alt-linux2/arch/x86/kernel/cpu/mkcapflags.sh2008-12-28
18:08:50.0 -0600
@@ -0,0 +1,28 @@
+#!/bin/bash
+#
+# Generate the x86_cap_flags[] array from include/asm/cpufeature.h
+#
+
+IN=$1
+OUT=$2
+
+(
+ echo "#include "
+ echo ""
+ echo "const char * const x86_cap_flags[NCAPINTS*32] = {"
+
+ # Iterate through any input lines starting with #define X86_FEATURE_
+ sed -n -e 's/\t/ /g' -e 's/^ *# *define *X86_FEATURE_//p' $IN |
+ while read i
+ do
+ # Name is everything up to the first whitespace
+ NAME="$(echo "$i" | sed 's/ .*//')"
+
+ # If the /* comment */ starts with a quote string, grab that.
+ VALUE="$(echo "$i" | sed -n 's...@.*/\*
*\("[^"]*"\).*\*/@\...@p')"
+ [ -z "$VALUE" ] && VALUE="\"$(echo "$NAME" | tr A-Z a-z)\""
+
+ [ "$VALUE" != '""' ] && echo " [X86_FEATURE_$NAME] = $VALUE,"
+ done
+ echo "};"
+) > $OUT
PATCH [0/3]: Simplify the kernel build by removing perl.
Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel never required perl to be installed on the build system. (Various development and debugging scripts were written in perl and python and such, but they weren't involved in actually building a kernel.) Building a kernel before 2.6.25 could be done with a minimal system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux kernel, and nothing else. (Embedded developers creating clean cross compile environments that won't leak bits of the host system into the target, or bootstrapping native development environments to run on target hardware or under emulators, tend to care about this sort of thing.) The perl checkin for 2.6.25 was the camel's nose under the tent flap, and since then two more instances of perl have shown up in the core kernel build. This patch series removes the three required to build a basic kernel for qemu for the targets I've tested (arm, mips, powerpc, sparc, m68k, sh4, and of course x86 and x86-64), replacing them with shell scripts. Historically the kernel has gone out of its way to minimize environmental dependencies for the build. For example, the plethora of *_shipped files mean we don't need lex and yacc to build the kernel. The kconfig infrastructure once required curses to run "make oldconfig", but that requirement was restricted to just menuconfig so the kernel could build on systems without ncurses. That was a very nice policy. Kernel development already requires an in-depth knowledge of C, make, and shell, plus things like the kconfig language. A similarly in-depth knowledge of perl is bigger than all that combined (even Larry Wall probably doesn't know all of Perl anymore), and then what's the excuse _not_ to add Python to the core build? And after that why not java, or lua? Where does it end? What's the criteria to say "no" here? This patch series saves time and says no now. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
Hi Rob.
On Fri, Jan 02, 2009 at 02:13:30AM -0600, Rob Landley wrote:
> From: Rob Landley
>
> Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell script
> is much simpler, about 1/4 the size, and runs on Red Hat 9 from 2003.
This part of the changelog is OK except that is fails to
address why we want to get away from perl.
Please drop the remining part of the changelog (but not the s-o-b).
> Peter Anvin added this perl to 2.6.25. Before that, the kernel had never
> required perl to build.
>
> Signed-off-by: Rob Landley
> ---
>
> kernel/Makefile |4
> kernel/timeconst.pl | 378 --
> kernel/timeconst.sh | 91 ++
> 3 files changed, 93 insertions(+), 380 deletions(-)
>
> diff -r d0c7611dcfd6 kernel/Makefile
> --- a/kernel/Makefile Tue Dec 30 17:48:25 2008 -0800
> +++ b/kernel/Makefile Fri Jan 02 00:10:44 2009 -0600
> @@ -115,7 +115,7 @@
> $(obj)/time.o: $(obj)/timeconst.h
>
> quiet_cmd_timeconst = TIMEC $@
> - cmd_timeconst = $(PERL) $< $(CONFIG_HZ) > $@
> + cmd_timeconst = $(CONFIG_SHELL) $< $(CONFIG_HZ) > $@
> targets += timeconst.h
> -$(obj)/timeconst.h: $(src)/timeconst.pl FORCE
> +$(obj)/timeconst.h: $(src)/timeconst.sh FORCE
> $(call if_changed,timeconst)
OK
> --- /dev/null 1969-12-31 00:00:00.0 -0600
> +++ hg/kernel/timeconst.sh2009-01-01 23:53:17.0 -0600
> @@ -0,0 +1,91 @@
> +#!/bin/bash
> +
> +if [ $# -ne 1 ]
> +then
> + echo "Usage: timeconst.sh HZ"
> + exit 1
> +fi
That usage is useless. Either extend it or spend a few lines
in the shell script explainign what the shell script is supposed to do.
> +
> +HZ=$1
> +
> +# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit
> math.
> +
> +[ $((1<<32)) -lt 0 ] && exit 1
> +
If it fails then add an error message explaining why. So if we get reports that
this
fails then we at least can see something like:
"timeconst noticed that the shell did not support 64 bit math - stop"
> +# Output start of header file
> +
> +cat << EOF
> +/* Automatically generated by kernel/timeconst.sh */
> +/* Conversion constants for HZ == $HZ */
> +
> +#ifndef KERNEL_TIMECONST_H
> +#define KERNEL_TIMECONST_H
Please use __KERNEL_TIMECONST_H. The two underscores are standard.
> +
> +#include
> +#include
> +
> +#if HZ != $HZ
> +#error "kernel/timeconst.h has the wrong HZ value!"
> +#endif
> +
> +EOF
> +
> +# For both Miliseconds and Microseconds
> +
> +for i in "MSEC 1000" "USEC 100"
> +do
> + NAME=$(echo $i | awk '{print $1}')
> + PERIOD=$(echo $i | awk '{print $2}')
> +
> + # Find greatest common denominator (using Euclid's algorithm)
> +
> + A=$HZ
> + B=$PERIOD
> +
> + while [ $B -ne 0 ]
> + do
> + C=$(($A%$B))
> + A=$B
> + B=$C
> + done
> +
> + GCD=$A
> +
> + # Do this for each direction (HZ_TO_PERIOD and PERIOD_TO_HZ)
> +
> + for DIRECTION in 0 1
> + do
> + if [ $DIRECTION -eq 0 ]
> + then
> + CONVERT="HZ_TO_${NAME}"
> + FROM=$HZ
> + TO=$PERIOD
> + else
> + CONVERT="${NAME}_TO_HZ"
> + FROM=$PERIOD
> + TO=$HZ
> + fi
> +
> + # How many shift bits give 32 bits of significant data?
> +
> + SHIFT=0
> + while [ $(( (($TO<<$SHIFT)+$FROM-1)/$FROM )) -lt $((1<<31)) ]
> + do
> + SHIFT=$(( $SHIFT+1 ))
> + done
> +
> + MUL32=$(( (($TO<<$SHIFT)+$FROM-1)/$FROM ))
> + MUL32=$(printf %x $MUL32)
> + echo "#define ${CONVERT}_MUL32 U64_C(0x$MUL32)"
> + ADJ32=$(($FROM/$GCD))
> + ADJ32=$(( (($ADJ32-1)<<$SHIFT)/$ADJ32 ))
> + ADJ32=$(printf %x $ADJ32)
> + echo "#define ${CONVERT}_ADJ32 U64_C(0x$ADJ32)"
> + echo "#define ${CONVERT}_SHR32 $SHIFT"
> + echo "#define ${CONVERT}_NUMU64_C($(($TO/$GCD)))"
> + echo "#define ${CONVERT}_DENU64_C($(($FROM/$GCD)))"
> + done
> +done
Is it a shell limitation that all spaces around operators are missing?
Makes it hard to read..
You should use trap in your shell script so we do not end up with a
partially generated file.
Or you should change the rule in the Makefile to use
a temperary file and then rename it.
We have similar bugs in other places - but no need to add
in more places.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3]: Remove perl from make headers_install
On Fri, Jan 02, 2009 at 02:14:32AM -0600, Rob Landley wrote: > From: Rob Landley > > Remove perl from make headers_install by replacing a perl script (doing > a simple regex search and replace) with a smaller and faster shell script > implementation. The new shell script is a single for loop calling sed and > piping its output through unifdef to produce the target file. OK > > Sam Ravnborg added this perl to 2.6.27. Drop this part - this is just to make you happy and for no use for others. > > Signed-off-by: Rob Landley > --- > > scripts/Makefile.headersinst |6 ++-- > scripts/headers_install.pl | 46 - > scripts/headers_install.sh | 23 > 3 files changed, 26 insertions(+), 49 deletions(-) > > --- /dev/null 2008-11-21 04:46:41.0 -0600 > +++ b/scripts/headers_install.sh 2008-12-15 22:09:45.0 -0600 > @@ -0,0 +1,23 @@ > +#!/bin/bash > + > +# Grab arguments > + > +INDIR="$1" > +shift > +OUTDIR="$1" > +shift > +ARCH="$1" > +shift Please add a short explanation what this file is used for and what it does. You can take more or less a direct copy from headers_install.pl > + > +# Iterate through files listed on command line > + > +for i in "$@" > +do > + sed -r \ > + -e 's/([ \t(])(__user|__force|__iomem)[ \t]/\1/g' \ > + -e 's/__attribute_const__([ \t]|$)/\1/g' \ > + -e 's...@^#include @@' "$INDIR/$i" | > + scripts/unifdef -U__KERNEL__ - > "$OUTDIR/$i" > +done > + > +exit 0 > diff -r d9b501c91442 scripts/Makefile.headersinst > --- a/scripts/Makefile.headersinstSun Dec 14 16:25:19 2008 -0800 > +++ b/scripts/Makefile.headersinstMon Dec 15 23:30:15 2008 -0600 > @@ -44,8 +44,8 @@ > quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\ > file$(if $(word 2, $(all-files)),s)) >cmd_install = \ > -$(PERL) $< $(srctree)/$(obj) $(install) $(SRCARCH) $(header-y); \ > -$(PERL) $< $(objtree)/$(obj) $(install) $(SRCARCH) $(objhdr-y); \ > + $(CONFIG_SHELL) $< $(srctree)/$(obj) $(install) $(SRCARCH) > $(header-y); \ > + $(CONFIG_SHELL) $< $(objtree)/$(obj) $(install) $(SRCARCH) > $(objhdr-y); \ Stick to the coding style i the file and do not add your own. Makefile.headersinst uses tabs for commands and not for indent. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3]: Convert mkcapflags.pl to mkcapflags.sh
On Fri, Jan 02, 2009 at 02:15:36AM -0600, Rob Landley wrote: > From: Rob Landley > > Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh. > > This script generates kernel/cpu/capflags.c from include/asm/cpufeature.h. OK > Peter Anvin added this perl to 2.6.28. Drop it. Implementation looks OK. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Friday 02 of January 2009, Rob Landley wrote: > Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) > building a Linux kernel never required perl to be installed on the build > system. (Various development and debugging scripts were written in perl > and python and such, but they weren't involved in actually building a > kernel.) Building a kernel before 2.6.25 could be done with a minimal > system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux > kernel, and nothing else. And now bash is going to be required... while some distros don't need/have bash. /bin/sh should be enough. Heh, -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote: > On Friday 02 of January 2009, Rob Landley wrote: > > Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) > > building a Linux kernel never required perl to be installed on the build > > system. (Various development and debugging scripts were written in perl > > and python and such, but they weren't involved in actually building a > > kernel.) Building a kernel before 2.6.25 could be done with a minimal > > system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux > > kernel, and nothing else. > > And now bash is going to be required... while some distros don't need/have > bash. /bin/sh should be enough. *nod* bash is in many ways a worse requirement than perl. strict posix /bin/sh + awk + sed would be nicest, but if that's too much work perl seems reasonable. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Fri, Jan 02, 2009 at 02:07:28AM -0600, Rob Landley wrote: > Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) > building a Linux kernel never required perl to be installed on the build > system. (Various development and debugging scripts were written in perl and > python and such, but they weren't involved in actually building a kernel.) > Building a kernel before 2.6.25 could be done with a minimal system built > from > gcc, binutils, bash, make, busybox, uClibc, and the Linux kernel, and nothing > else. (Embedded developers creating clean cross compile environments that > won't leak bits of the host system into the target, or bootstrapping native > development environments to run on target hardware or under emulators, tend > to > care about this sort of thing.) > > The perl checkin for 2.6.25 was the camel's nose under the tent flap, and > since then two more instances of perl have shown up in the core kernel build. > > This patch series removes the three required to build a basic kernel for qemu > for the targets I've tested (arm, mips, powerpc, sparc, m68k, sh4, and of > course x86 and x86-64), replacing them with shell scripts. Misguided rhetoric aside, what does this actually accomplish? If folks add meaningful tools in to the kernel that require python, and it is generally regarded as being fairly ubiquitous, I can't imagine there being any substantiated objections against it. Your main reasons against inclusion of perl seem to be that there is no realistic expectation for target systems that will be self-hosting will have perl included, or the inherent complexity in maintaining a coherent cross compiling environment. Both of these things are issues with your own environment, and in no way are these representative of the embedded development community at large. Now with that out of the way, this entire series fundamentally fails to convert half of the perl scripts shipped with the kernel today, some that are required for build depending on Kconfig options, and others that are simply useful tools for self-hosted environments. Simply converting a couple of scripts over you find objectionable is certainly fine if there is a real benefit in doing so, but this doesn't actually accomplish your goal of removing the perl dependency. Ignoring the compile-time dependencies that you overlooked, what you define as "development and debugging" scripts are still an integral part of the system, unless you are trying to argue that embedded developers have no interest in things like checkstack due to the trouble of trying to get perl built. Until you can post a series that converts all of scripts/*.pl in its entirety, you have failed to address the fundamental reason why perl is used in the first place. Trying to toss bizarre policy statements around regarding things you personally find objectionable without any coherent technical argument to the contrary is of no constructive use whatsoever. The kernel is and always has been about using the right tool for the job, not a matter of dictating what tools you must use in order to accomplish a task you are interested in. Common sense does apply here though, so this might be a more daunting task for some than others. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Jan 2, 2009, at 3:26 AM, Arkadiusz Miskiewicz wrote: On Friday 02 of January 2009, Rob Landley wrote: Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel never required perl to be installed on the build system. (Various development and debugging scripts were written in perl and python and such, but they weren't involved in actually building a kernel.) Building a kernel before 2.6.25 could be done with a minimal system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux kernel, and nothing else. And now bash is going to be required... while some distros don't need/have bash. /bin/sh should be enough. Which distros only have /bin/sh which do not have Perl? I'm honestly curious. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ -- Mark Miller m...@mirell.org -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Jan 2, 2009, at 4:02 AM, Mark Miller wrote: On Jan 2, 2009, at 3:26 AM, Arkadiusz Miskiewicz wrote: On Friday 02 of January 2009, Rob Landley wrote: Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel never required perl to be installed on the build system. (Various development and debugging scripts were written in perl and python and such, but they weren't involved in actually building a kernel.) Building a kernel before 2.6.25 could be done with a minimal system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux kernel, and nothing else. And now bash is going to be required... while some distros don't need/have bash. /bin/sh should be enough. Which distros only have /bin/sh which do not have Perl? I'm honestly curious. That is, *do* have Perl. Typo there. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ -- Mark Miller m...@mirell.org -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
Christoph Hellwig escribió: > On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote: > >> On Friday 02 of January 2009, Rob Landley wrote: >> >>> Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) >>> building a Linux kernel never required perl to be installed on the build >>> system. (Various development and debugging scripts were written in perl >>> and python and such, but they weren't involved in actually building a >>> kernel.) Building a kernel before 2.6.25 could be done with a minimal >>> system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux >>> kernel, and nothing else. >>> >> And now bash is going to be required... while some distros don't need/have >> bash. /bin/sh should be enough. >> > > *nod* bash is in many ways a worse requirement than perl. strict posix > /bin/sh + awk + sed would be nicest, but if that's too much work perl > seems reasonable. well, bash is not worse as bash is trivial to cross-compile to run on a constrained sandbox and perl is a nightmare, but I agree bash should be avoided too. I think the $(( ... )) bash-ism can be replaced with a simple .c helper toy. Thank Rob for reopening the topic. Alejandro Mery smime.p7s Description: S/MIME Cryptographic Signature
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Jan 2, 2009, at 4:16 AM, Alejandro Mery wrote: Christoph Hellwig escribió: On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote: On Friday 02 of January 2009, Rob Landley wrote: Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel never required perl to be installed on the build system. (Various development and debugging scripts were written in perl and python and such, but they weren't involved in actually building a kernel.) Building a kernel before 2.6.25 could be done with a minimal system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux kernel, and nothing else. And now bash is going to be required... while some distros don't need/have bash. /bin/sh should be enough. *nod* bash is in many ways a worse requirement than perl. strict posix /bin/sh + awk + sed would be nicest, but if that's too much work perl seems reasonable. well, bash is not worse as bash is trivial to cross-compile to run on a constrained sandbox and perl is a nightmare, but I agree bash should be avoided too. I think the $(( ... )) bash-ism can be replaced with a simple .c helper toy. Thank Rob for reopening the topic. Alejandro Mery And actually, one of the things that I just recalled, is that several of the Perl configure scripts in order to actually build itself, rely on Bourne shell calls. So the argument to require a strict POSIX+sed +awk implementation rather than Perl to build the kernel, fails, since you already require some variant of shell greater than strict POSIX / bin/sh to build Perl. So this is one less dependency. Also, attempting to cross-compile Perl, is indeed a nightmare. -- Mark Miller m...@mirell.org -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Fri, Jan 02, 2009 at 04:32:42AM -0600, Mark Miller wrote: > On Jan 2, 2009, at 3:50 AM, Paul Mundt wrote: > >Misguided rhetoric aside, what does this actually accomplish? If folks > >add meaningful tools in to the kernel that require python, and it is > >generally regarded as being fairly ubiquitous, I can't imagine there > >being any substantiated objections against it. > > And if the said meaningful tools introduce complex dependencies, then > there should be an open discussion as to why exactly we need those > tools as opposed to a simpler implementation. > Complex is relative, something that is fairly ubiquitious can hardly be labelled as complex, regardless of whether historically people have had issues with that dependency in certain spaces. In any event, simplifying things is always good, but this open discussion thing is pure fancy, since when was the kernel a democracy? > >Your main reasons against inclusion of perl seem to be that there is > >no realistic expectation for target systems that will be self-hosting > >will have perl included, or the inherent complexity in maintaining a > >coherent cross compiling environment. Both of these things are issues > >with your own environment, and in no way are these representative of > >the embedded development community at large. > > I feel that if you attempted to look for discussions on "cross- > compiling perl", you will meet with a variety of complaints on what a > nightmare it is to do so in a sandboxed environment. > I've had to deal with cross compiling perl for over a decade, in all of its various forms, in all manner of embedded applications, so please tell someone who cares. There are various options around this headache today, as there have been for ages (though the options these days are rather less painful), and if you felt like attempting to look for discussions on those rather than trying to push this silly matter perhaps you might come up with something. The key thing you hit on is that there are a variety of complaints, and that is all they have ever been. If your system is so constrained, you shouldn't be doing builds on it in the first place. You certainly won't be able to build anything in your crippled environment outside of some simple applications anyways, this isn't a valid technical reason for keeping the kernel a policy stranglehold. > >Now with that out of the way, this entire series fundamentally fails > >to convert half of the perl scripts shipped with the kernel today, > >some that are required for build depending on Kconfig options, > [snip] > From what I can tell, it allows one to fully build the Linux kernel > without Perl. Wrong, re-read what I said and try again. > >Ignoring the compile-time dependencies that you overlooked, what you > >define as "development and debugging" scripts are still an integral > >part of the system, unless you are trying to argue that embedded > >developers have no interest in things like checkstack due to the > >trouble of trying to get perl built. > > Do I need that to compile a kernel? No. > Compile-time dependencies you do, yes. > Perl was not required to build the Linux kernel. Now it is. It adds > another dependency to the Linux kernel. Requiring bash is far less a > dependency that Perl is. > Perhaps so, but that is largely irrelevant. Moving off of the bash dependency is a lot more trivial than moving off of the perl one. The kernel bashisms are fairly marginal, and if someone were to do the leg work for that, it might even be accepted. Getting rid of perl is an uphill battle for no visible gain. People will continue to write and add scripts both in bash and perl on a routine basis regardless. > >The kernel is and always has been about using the right tool for the > >job, not a matter of dictating what tools you must use in order to > >accomplish a task you are interested in. Common sense does apply here > >though, so this might be a more daunting task for some than others. > > How is Perl a better tool for the job than what currently bash and > other standard utilities already offer? > How is bash a better tool for than job than what sed and posix shell already offer? Yes, we can reduce our dependencies to the bare minimum, but that is not constructive for the folks that are actually writing the scripts in the first place. Likewise, this is not even a real problem in the embedded developer demographic, the only place this is a problem is in specially stripped distributions or people that don't want to go through the pain of cross compiling perl. None of which is of any concern. If people are going to write useful things that are reasonably expected to be standard on build machines, there is no reason to restrict what tools they are permitted to use. If you have a personal vendetta against something that is fairly standard, that is entirely your own personal problem, you can choose to deal with it or patch out of tree for your own crippled envi
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote: > On Friday 02 of January 2009, Rob Landley wrote: > > Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 > > ) building a Linux kernel never required perl to be installed on the > > build system. (Various development and debugging scripts were written in > > perl and python and such, but they weren't involved in actually building > > a kernel.) Building a kernel before 2.6.25 could be done with a minimal > > system built from gcc, binutils, bash, make, busybox, uClibc, and the > > Linux kernel, and nothing else. > > And now bash is going to be required... while some distros don't need/have > bash. /bin/sh should be enough. > > Heh, I believe all three scripts run under dash and busybox ash. (The timeconst.sh one needs 64 bit math which dash only provides on 64 bit hosts, which is a regression from Red Hat 9 in 2003 by the way. Busybox ash can also provide 64 bit math on 32 bit hosts, and the script should run with that just fine if you haven't got bash and that's what your "sh" in the path is.) The makefiles execute those scripts via CONFIG_SHELL, not via the #!/blah line at the start, so it's largely irrelevant what gets put there anyway. If you haven't got bash installed it'll use "sh", which should work with dash on a 64 bit host or with busybox ash. (That's why that one file has a test to make sure 64 bit math _does_ work. The only Linux development environment I'm aware of where that test would trigger is if you use a 32 bit ubuntu and go out of your way to _uninstall_ bash. Even Cygwin uses bash.) Beyond that, "find linux -type f | xargs grep bin/bash | wc" comes up with 38 instances (admittedly half of 'em in Documentation, but lots in scripts, and makefiles, and defconfigs, at least one hardwired in C code.) So this would not a _new_ dependency. By the way, what Linux distros install a compiler toolchain but not bash? I'm curious. (Even after Ubuntu moved #!/bin/sh to point to dash, it still installs bash as part of the default environment, even if you don't install development tools.) You've built the kernel on this system before? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Friday 02 January 2009 04:16:53 Alejandro Mery wrote: > Christoph Hellwig escribió: > > On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote: > >> On Friday 02 of January 2009, Rob Landley wrote: > >>> Before 2.6.25 (specifically git > >>> bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel > >>> never required perl to be installed on the build system. (Various > >>> development and debugging scripts were written in perl and python and > >>> such, but they weren't involved in actually building a kernel.) > >>> Building a kernel before 2.6.25 could be done with a minimal system > >>> built from gcc, binutils, bash, make, busybox, uClibc, and the Linux > >>> kernel, and nothing else. > >> > >> And now bash is going to be required... while some distros don't > >> need/have bash. /bin/sh should be enough. > > > > *nod* bash is in many ways a worse requirement than perl. strict posix > > /bin/sh + awk + sed would be nicest, but if that's too much work perl > > seems reasonable. > > well, bash is not worse as bash is trivial to cross-compile to run on a > constrained sandbox and perl is a nightmare, but I agree bash should be > avoided too. > > I think the $(( ... )) bash-ism can be replaced with a simple .c helper > toy. No, $[ ] is the bashism, $(( )) is susv3: http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04 I intentionally switched from $[ ] to $(( )) to make dash work. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Fri, 2009-01-02 at 04:30 -0600, Mark Miller wrote: > On Jan 2, 2009, at 4:16 AM, Alejandro Mery wrote: > > > Christoph Hellwig escribió: > >> On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote: > >> > >>> On Friday 02 of January 2009, Rob Landley wrote: > >>> > Before 2.6.25 (specifically git > bdc807871d58285737d50dc6163d0feb72cb0dc2 ) > building a Linux kernel never required perl to be installed on > the build > system. (Various development and debugging scripts were written > in perl > and python and such, but they weren't involved in actually > building a > kernel.) Building a kernel before 2.6.25 could be done with a > minimal > system built from gcc, binutils, bash, make, busybox, uClibc, and > the Linux > kernel, and nothing else. > > >>> And now bash is going to be required... while some distros don't > >>> need/have > >>> bash. /bin/sh should be enough. > >>> > >> > >> *nod* bash is in many ways a worse requirement than perl. strict > >> posix > >> /bin/sh + awk + sed would be nicest, but if that's too much work perl > >> seems reasonable. > > >> > > well, bash is not worse as bash is trivial to cross-compile to run > > on a > > constrained sandbox and perl is a nightmare, but I agree bash should > > be > > avoided too. > > > > I think the $(( ... )) bash-ism can be replaced with a simple .c > > helper toy. > > > > Thank Rob for reopening the topic. > > > > Alejandro Mery > > And actually, one of the things that I just recalled, is that several > of the Perl configure scripts in order to actually build itself, rely > on Bourne shell calls. So the argument to require a strict POSIX+sed > +awk implementation rather than Perl to build the kernel, fails, since > you already require some variant of shell greater than strict POSIX / > bin/sh to build Perl. So this is one less dependency. > > Also, attempting to cross-compile Perl, is indeed a nightmare. > Having cross compiled Perl, on to a Unix with a brain dead third party TCP/IP no less, only 4 years after starting to use Unix / Linux I can attest that it is not that difficult to cross compile. Heck it even runs on those weird Crays that don't know which byte sex they are. Matt -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Jan 2, 2009, at 3:50 AM, Paul Mundt wrote: On Fri, Jan 02, 2009 at 02:07:28AM -0600, Rob Landley wrote: Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel never required perl to be installed on the build system. (Various development and debugging scripts were written in perl and python and such, but they weren't involved in actually building a kernel.) Building a kernel before 2.6.25 could be done with a minimal system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux kernel, and nothing else. (Embedded developers creating clean cross compile environments that won't leak bits of the host system into the target, or bootstrapping native development environments to run on target hardware or under emulators, tend to care about this sort of thing.) The perl checkin for 2.6.25 was the camel's nose under the tent flap, and since then two more instances of perl have shown up in the core kernel build. This patch series removes the three required to build a basic kernel for qemu for the targets I've tested (arm, mips, powerpc, sparc, m68k, sh4, and of course x86 and x86-64), replacing them with shell scripts. Misguided rhetoric aside, what does this actually accomplish? If folks add meaningful tools in to the kernel that require python, and it is generally regarded as being fairly ubiquitous, I can't imagine there being any substantiated objections against it. And if the said meaningful tools introduce complex dependencies, then there should be an open discussion as to why exactly we need those tools as opposed to a simpler implementation. Your main reasons against inclusion of perl seem to be that there is no realistic expectation for target systems that will be self-hosting will have perl included, or the inherent complexity in maintaining a coherent cross compiling environment. Both of these things are issues with your own environment, and in no way are these representative of the embedded development community at large. I feel that if you attempted to look for discussions on "cross- compiling perl", you will meet with a variety of complaints on what a nightmare it is to do so in a sandboxed environment. Now with that out of the way, this entire series fundamentally fails to convert half of the perl scripts shipped with the kernel today, some that are required for build depending on Kconfig options, and others that are simply useful tools for self-hosted environments. Simply converting a couple of scripts over you find objectionable is certainly fine if there is a real benefit in doing so, but this doesn't actually accomplish your goal of removing the perl dependency. From what I can tell, it allows one to fully build the Linux kernel without Perl. Without these series of patches, to actually *build* the kernel, one requires Perl. Unless there is an alternate way to do "make headers_install" that I am not seeing, that appears to now be done in Perl. All the other Perl scripts were merely nice to have, not necessary to build a Linux kernel. Ignoring the compile-time dependencies that you overlooked, what you define as "development and debugging" scripts are still an integral part of the system, unless you are trying to argue that embedded developers have no interest in things like checkstack due to the trouble of trying to get perl built. Do I need that to compile a kernel? No. Until you can post a series that converts all of scripts/*.pl in its entirety, you have failed to address the fundamental reason why perl is used in the first place. Trying to toss bizarre policy statements around regarding things you personally find objectionable without any coherent technical argument to the contrary is of no constructive use whatsoever. Perl was not required to build the Linux kernel. Now it is. It adds another dependency to the Linux kernel. Requiring bash is far less a dependency that Perl is. The kernel is and always has been about using the right tool for the job, not a matter of dictating what tools you must use in order to accomplish a task you are interested in. Common sense does apply here though, so this might be a more daunting task for some than others. How is Perl a better tool for the job than what currently bash and other standard utilities already offer? -- Mark Miller m...@mirell.org -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Fri, Jan 02, 2009 at 05:15:32AM -0600, Rob Landley wrote: > On Friday 02 January 2009 04:16:53 Alejandro Mery wrote: > > Christoph Hellwig escribió: > > > On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote: > > >> On Friday 02 of January 2009, Rob Landley wrote: > > >>> Before 2.6.25 (specifically git > > >>> bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel > > >>> never required perl to be installed on the build system. (Various > > >>> development and debugging scripts were written in perl and python and > > >>> such, but they weren't involved in actually building a kernel.) > > >>> Building a kernel before 2.6.25 could be done with a minimal system > > >>> built from gcc, binutils, bash, make, busybox, uClibc, and the Linux > > >>> kernel, and nothing else. > > >> > > >> And now bash is going to be required... while some distros don't > > >> need/have bash. /bin/sh should be enough. > > > > > > *nod* bash is in many ways a worse requirement than perl. strict posix > > > /bin/sh + awk + sed would be nicest, but if that's too much work perl > > > seems reasonable. > > > > well, bash is not worse as bash is trivial to cross-compile to run on a > > constrained sandbox and perl is a nightmare, but I agree bash should be > > avoided too. > > > > I think the $(( ... )) bash-ism can be replaced with a simple .c helper > > toy. > > No, $[ ] is the bashism, $(( )) is susv3: > http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04 > > I intentionally switched from $[ ] to $(( )) to make dash work. The focus on this patch is to create a minimal set of dependencies so please document what dependencies / compatibility this patch introduces. It is not obvious for me for example if the script requires sh, bash or dash or whatever. The shebang is so often wrong that this is not docuemnting such things. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Friday 02 January 2009 03:04:39 Sam Ravnborg wrote:
> Hi Rob.
>
> On Fri, Jan 02, 2009 at 02:13:30AM -0600, Rob Landley wrote:
> > From: Rob Landley
> >
> > Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell
> > script is much simpler, about 1/4 the size, and runs on Red Hat 9 from
> > 2003.
>
> This part of the changelog is OK except that is fails to
> address why we want to get away from perl.
You mean "The new shell script is much simpler, about 1/4 the size, runs on
Red Hat 9 from 2003, and isn't perl?" :)
> Please drop the remining part of the changelog (but not the s-o-b).
ok.
> > Peter Anvin added this perl to 2.6.25. Before that, the kernel had never
> > required perl to build.
> >
> > Signed-off-by: Rob Landley
> > ---
> >
> > kernel/Makefile |4
> > kernel/timeconst.pl | 378 --
> > kernel/timeconst.sh | 91 ++
> > 3 files changed, 93 insertions(+), 380 deletions(-)
> >
> > diff -r d0c7611dcfd6 kernel/Makefile
> > --- a/kernel/Makefile Tue Dec 30 17:48:25 2008 -0800
> > +++ b/kernel/Makefile Fri Jan 02 00:10:44 2009 -0600
> > @@ -115,7 +115,7 @@
> > $(obj)/time.o: $(obj)/timeconst.h
> >
> > quiet_cmd_timeconst = TIMEC $@
> > - cmd_timeconst = $(PERL) $< $(CONFIG_HZ) > $@
> > + cmd_timeconst = $(CONFIG_SHELL) $< $(CONFIG_HZ) > $@
> > targets += timeconst.h
> > -$(obj)/timeconst.h: $(src)/timeconst.pl FORCE
> > +$(obj)/timeconst.h: $(src)/timeconst.sh FORCE
> > $(call if_changed,timeconst)
>
> OK
>
> > --- /dev/null 1969-12-31 00:00:00.0 -0600
> > +++ hg/kernel/timeconst.sh 2009-01-01 23:53:17.0 -0600
> > @@ -0,0 +1,91 @@
> > +#!/bin/bash
> > +
> > +if [ $# -ne 1 ]
> > +then
> > + echo "Usage: timeconst.sh HZ"
> > + exit 1
> > +fi
>
> That usage is useless. Either extend it or spend a few lines
> in the shell script explainign what the shell script is supposed to do.
Do you mean something more like:
echo "Usage: timeconst.sh HZ"
echo
echo "Generates a header file of constants for converting between decimal"
echo "HZ timer ticks and milisecond or microsecond delays"
I'm happy turning it into a comment instead, I just found a quick check that
I'd remembered to type an argument useful during debugging. :)
> > +
> > +HZ=$1
> > +
> > +# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit
> > math. +
> > +[ $((1<<32)) -lt 0 ] && exit 1
> > +
>
> If it fails then add an error message explaining why. So if we get reports
> that this fails then we at least can see something like:
> "timeconst noticed that the shell did not support 64 bit math - stop"
Ok.
> > +# Output start of header file
> > +
> > +cat << EOF
> > +/* Automatically generated by kernel/timeconst.sh */
> > +/* Conversion constants for HZ == $HZ */
> > +
> > +#ifndef KERNEL_TIMECONST_H
> > +#define KERNEL_TIMECONST_H
>
> Please use __KERNEL_TIMECONST_H. The two underscores are standard.
Sure thing. (I was just copying the perl there, I'll post an updated patch
after I get some sleep.)
> > +
> > +#include
> > +#include
> > +
> > +#if HZ != $HZ
> > +#error "kernel/timeconst.h has the wrong HZ value!"
> > +#endif
> > +
> > +EOF
> > +
> > +# For both Miliseconds and Microseconds
> > +
> > +for i in "MSEC 1000" "USEC 100"
> > +do
> > + NAME=$(echo $i | awk '{print $1}')
> > + PERIOD=$(echo $i | awk '{print $2}')
> > +
> > + # Find greatest common denominator (using Euclid's algorithm)
> > +
> > + A=$HZ
> > + B=$PERIOD
> > +
> > + while [ $B -ne 0 ]
> > + do
> > + C=$(($A%$B))
> > + A=$B
> > + B=$C
> > + done
> > +
> > + GCD=$A
> > +
> > + # Do this for each direction (HZ_TO_PERIOD and PERIOD_TO_HZ)
> > +
> > + for DIRECTION in 0 1
> > + do
> > + if [ $DIRECTION -eq 0 ]
> > + then
> > + CONVERT="HZ_TO_${NAME}"
> > + FROM=$HZ
> > + TO=$PERIOD
> > + else
> > + CONVERT="${NAME}_TO_HZ"
> > + FROM=$PERIOD
> > + TO=$HZ
> > + fi
> > +
> > + # How many shift bits give 32 bits of significant data?
> > +
> > + SHIFT=0
> > + while [ $(( (($TO<<$SHIFT)+$FROM-1)/$FROM )) -lt $((1<<31)) ]
> > + do
> > + SHIFT=$(( $SHIFT+1 ))
> > + done
> > +
> > + MUL32=$(( (($TO<<$SHIFT)+$FROM-1)/$FROM ))
> > + MUL32=$(printf %x $MUL32)
> > + echo "#define ${CONVERT}_MUL32 U64_C(0x$MUL32)"
> > + ADJ32=$(($FROM/$GCD))
> > + ADJ32=$(( (($ADJ32-1)<<$SHIFT)/$ADJ32 ))
> > + ADJ32=$(printf %x $ADJ32)
> > + echo "#define ${CONVERT}_ADJ32 U64_C(0x$ADJ32)"
> > + echo "#define ${CONVERT}_SHR32 $SHIFT"
> > + echo "#define ${CONVERT}_NUMU64_C($(($TO/$GCD)))"
> > + echo "#define ${CONVERT}_DENU64_C($(($FROM/$GCD)))"
> >
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Jan 2, 2009, at 4:57 AM, Paul Mundt wrote: On Fri, Jan 02, 2009 at 04:32:42AM -0600, Mark Miller wrote: On Jan 2, 2009, at 3:50 AM, Paul Mundt wrote: Misguided rhetoric aside, what does this actually accomplish? If folks add meaningful tools in to the kernel that require python, and it is generally regarded as being fairly ubiquitous, I can't imagine there being any substantiated objections against it. And if the said meaningful tools introduce complex dependencies, then there should be an open discussion as to why exactly we need those tools as opposed to a simpler implementation. Complex is relative, something that is fairly ubiquitious can hardly be labelled as complex, regardless of whether historically people have had issues with that dependency in certain spaces. In any event, simplifying things is always good, but this open discussion thing is pure fancy, since when was the kernel a democracy? I'm ignoring the bait. Your main reasons against inclusion of perl seem to be that there is no realistic expectation for target systems that will be self- hosting will have perl included, or the inherent complexity in maintaining a coherent cross compiling environment. Both of these things are issues with your own environment, and in no way are these representative of the embedded development community at large. I feel that if you attempted to look for discussions on "cross- compiling perl", you will meet with a variety of complaints on what a nightmare it is to do so in a sandboxed environment. I've had to deal with cross compiling perl for over a decade, in all of its various forms, in all manner of embedded applications, so please tell someone who cares. Ignoring this as well. There are various options around this headache today, as there have been for ages (though the options these days are rather less painful), and if you felt like attempting to look for discussions on those rather than trying to push this silly matter perhaps you might come up with something. And ignoring this too. The key thing you hit on is that there are a variety of complaints, and that is all they have ever been. If your system is so constrained, you shouldn't be doing builds on it in the first place. You certainly won't be able to build anything in your crippled environment outside of some simple applications anyways, this isn't a valid technical reason for keeping the kernel a policy stranglehold. I merely don't like seeing another dependency added when there's no logical reason to do it, other than "why not". And there have been reasons given for the "not". Your reply, seems merely to be, "Because." Now with that out of the way, this entire series fundamentally fails to convert half of the perl scripts shipped with the kernel today, some that are required for build depending on Kconfig options, [snip] From what I can tell, it allows one to fully build the Linux kernel without Perl. Wrong, re-read what I said and try again. I have done so. And I restate, without these patches, Perl is required *for any install*. Your logic seems to be, if Perl is required for any part of doing something with the Linux kernel, then there is no reason it should not be allowed in all parts. With this logic, soon the Linux kernel will require so many dependencies, that even a minimal system to rebuild itself under itself will comprise 200MB for stripped binaries. Right now, it's down to about 20ish. With that, you also require more expertise in maintaing these variety of tools. You have given no logical reason on why we need to add more complexity to the kernel, when previous tools have managed to deal with this task for over ten years without requiring Perl. Ignoring the compile-time dependencies that you overlooked, what you define as "development and debugging" scripts are still an integral part of the system, unless you are trying to argue that embedded developers have no interest in things like checkstack due to the trouble of trying to get perl built. Do I need that to compile a kernel? No. Compile-time dependencies you do, yes. Perl was not required to build the Linux kernel. Now it is. It adds another dependency to the Linux kernel. Requiring bash is far less a dependency that Perl is. Perhaps so, but that is largely irrelevant. Moving off of the bash dependency is a lot more trivial than moving off of the perl one. The kernel bashisms are fairly marginal, and if someone were to do the leg work for that, it might even be accepted. Getting rid of perl is an uphill battle for no visible gain. People will continue to write and add scripts both in bash and perl on a routine basis regardless. The kernel is and always has been about using the right tool for the job, not a matter of dictating what tools you must use in order to accomplish a task you are interested in. Common sense does apply here though, so this might be a more daunting
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Friday 02 January 2009 03:50:23 Paul Mundt wrote: > On Fri, Jan 02, 2009 at 02:07:28AM -0600, Rob Landley wrote: > > The perl checkin for 2.6.25 was the camel's nose under the tent flap, and > > since then two more instances of perl have shown up in the core kernel > > build. This patch series removes the three required to build a basic > > kernel for qemu for the targets I've tested (arm, mips, powerpc, sparc, > > m68k, sh4, and of course x86 and x86-64), replacing them with shell > > scripts. > > Misguided rhetoric aside, what does this actually accomplish? If folks > add meaningful tools in to the kernel that require python, and it is > generally regarded as being fairly ubiquitous, I can't imagine there > being any substantiated objections against it. I think bloat-o-meter is a marvelous tool, and I'm a big fan of python. But I don't think you shouldn't have to run that to compile a kernel either, largely because not needing it for the first 17 years or so implied living without this requirement could be done, sustainably even. There's a difference between a development workstation and a dedicated build system. Requiring you to install X11 plus qt on the headless build server cranking out nightly snapshots in order to run the configure stage of the kernel build would be silly. But this is not an argument for ripping out "make xconfig" from the kernel. Spot the difference? > Your main reasons against inclusion of perl seem to be that there is no > realistic expectation for target systems that will be self-hosting will > have perl included, or the inherent complexity in maintaining a coherent > cross compiling environment. I'm saying it's a major new environmental dependency that went in fairly recently and largely without comment, and it causes real world headaches for real people, of which I am only one. If you don't think environmental dependencies are a problem, I welcome you to attempt to build open office. (Even the gentoo guys gave up on that one and just started shipping a prebuilt binary.) I think large amounts of complexity start with small amounts of complexity that grow. Complexity is inevitable, but there should be a _reason_ for increases in it. > Both of these things are issues with your > own environment, and in no way are these representative of the embedded > development community at large. > > Now with that out of the way, this entire series fundamentally fails to > convert half of the perl scripts shipped with the kernel today, some that > are required for build depending on Kconfig options, and others that are > simply useful tools for self-hosted environments. I didn't say the job was finished. These are just the ones I've already personally hit, and thus A) needed to rewrite to build the kernel in my build environment, B) have a handy test case for. > Simply converting a > couple of scripts over you find objectionable is certainly fine if there > is a real benefit in doing so, but this doesn't actually accomplish your > goal of removing the perl dependency. A) It's a start. B) It works for me, and builds the .configs I've personally needed so far. > Ignoring the compile-time dependencies that you overlooked, what you > define as "development and debugging" scripts are still an integral part > of the system, unless you are trying to argue that embedded developers > have no interest in things like checkstack due to the trouble of trying > to get perl built. Coming up with new patches and modifying the source is a different use for source code than going "./configure; make; make install". This is true for most open source software, I'd expect. Or are you implying that eclipse or Emacs are such great IDEs that being able to build outside of a GUI isn't interesting? The ability to build within an IDE should be allowed to preclude the ability to build without one? > Until you can post a series that converts all of scripts/*.pl in its > entirety, you have failed to address the fundamental reason why perl is > used in the first place. Never start anything unless you can finish it all in one go, eh? Last I heard the kernel guys tend to frown on people who wander off in their own corner for a year and then dump a massive rewrite on them. They seem to prefer the incremental "trail of breadcrumbs" approach. Release early, release often, incorporate feedback, keep at it. Or am I wrong? > Trying to toss bizarre policy statements around > regarding things you personally find objectionable without any coherent > technical argument to the contrary is of no constructive use whatsoever. Complexity is a cost, environmental dependencies are a form of complexity, if the benefit isn't worth the cost (or you can get the benefit without the cost) then you shouldn't pay the cost. I was unaware this was a controversial attitude? > The kernel is and always has been about using the right tool for the job, > not a matter of dictating what tools you mus
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Friday 02 January 2009 03:49:34 Christoph Hellwig wrote: > On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote: > > On Friday 02 of January 2009, Rob Landley wrote: > > > Before 2.6.25 (specifically git > > > bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel > > > never required perl to be installed on the build system. (Various > > > development and debugging scripts were written in perl and python and > > > such, but they weren't involved in actually building a kernel.) > > > Building a kernel before 2.6.25 could be done with a minimal system > > > built from gcc, binutils, bash, make, busybox, uClibc, and the Linux > > > kernel, and nothing else. > > > > And now bash is going to be required... while some distros don't > > need/have bash. /bin/sh should be enough. > > *nod* bash is in many ways a worse requirement than perl. strict posix > /bin/sh + awk + sed would be nicest, but if that's too much work perl > seems reasonable. The scripts should work with dash (modulo the one that needs 64 bit math, which dash only provides on a 64 bit host), or with busybox ash (which can provide 64 bit math on 32 bit hosts just like bash can). I'll explicitly retest both of those when I respin the patches in the morning afternoon. (And yes I thought about writing my own arbitrary precision arithmetic shell functions, but it really didn't seem worth the complexity since the only 32 bit Linux distros I've seen that install dash also install bash by default. I just put in a test for 32 bit math so it can spot it and fail, on the off chance you're running a 32 bit host with dash after explicitly uninstalling bash. All the embedded 32 bit ones that try to act as development environments use busybox ash, or more often just install bash.) That said, how is bash _worse_ than perl? (Where's the second implementation of perl? Even Python had jython, but perl has... what? The attempt to rebase on Parrot went down in flames...) If the argument is that "depending on a specific shell implementation is as bad as depending on the one and only implementation of perl", that argument I can at least follow, even if it doesn't actually apply in this case. But where does "worse" come in? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On Fri, Jan 02, 2009 at 06:56:31AM -0600, Rob Landley wrote: > That said, how is bash _worse_ than perl? (Where's the second > implementation of perl? Even Python had jython, but perl > has... what? The attempt to rebase on Parrot went down in > flames...) (1) bash implies POSIX extensions; perl is actually quite portable. (2) There are distributions that install with perl by default but not bash; they use dash for speed reasons. Sounds like though modulo dealing with 64-bit arithmetic, your patches are mostly dash/POSIX.2 comformant, so you're probably mostly good on that front once you address the 32/64-bit issues. I'd also suggest explicitly add a reminder to the shell scripts' comments to avoid bashisms for maximum portability, to remind developers in the future who might try to change the shell scripts to watch out for portability issues. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
Rob Landley a écrit : > On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote: >> On Friday 02 of January 2009, Rob Landley wrote: >> >> Heh, > > I believe all three scripts run under dash and busybox ash. (The > timeconst.sh > one needs 64 bit math which dash only provides on 64 bit hosts, which is a > regression from Red Hat 9 in 2003 by the way. With dash 0.5.4-12 (from debian sid), I seems I got the 64 bit math for 32 bit hosts : $ uname -m i686 $ dash -c 'echo $((1<<32))' 4294967296 Matthieu -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
On 2009-01-02 18:50 +0900, Paul Mundt wrote: > Your main reasons against inclusion of perl seem to be that there is no > realistic expectation for target systems that will be self-hosting will > have perl included, or the inherent complexity in maintaining a coherent > cross compiling environment. Both of these things are issues with your > own environment, and in no way are these representative of the embedded > development community at large. It may well be true that most embedded people cross-build kernels and use native perl on a fat build box, but there are plenty of situations where being able to build kernels without perl is useful. Given the simplicitly of these patches I can't see any reason not to put them in, and appreciate Rob's work on this. And if cross-building perl is really easy, as some in this thread claim, can someone fix the Debian packages to do it, because that would be really useful (it appears to be of similar complexity to cross-building gcc, requiring a 2-stage self-referential build). Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/ -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
Hi Wookey. > Given the > simplicitly of these patches I can't see any reason not to put them > in Please do NOT do the mistake and think this the same thing. Rob's patch simplyfy the timecost stuff - and will be applied on this merit alone assuming comments will be addressed. But the serie rased anohter topic: shall we ban use of perl for generating a kernel. And this is what primary is discussed and the outcome of that discussion will not prevent patches that stands on their own to be applied. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
Sam Ravnborg wrote: > Hi Wookey. > >> Given the >> simplicitly of these patches I can't see any reason not to put them >> in > > Please do NOT do the mistake and think this the same thing. > > Rob's patch simplyfy the timecost stuff - and will be applied on > this merit alone assuming comments will be addressed. > > But the serie rased anohter topic: shall we ban use of perl > for generating a kernel. > And this is what primary is discussed and the outcome of > that discussion will not prevent patches that stands on their > own to be applied. > My personal opinion on this is that this is ridiculous. Given that you need gcc, binutils, make etc. to build the kernel, and this is more than inherent, you have to have a pretty bloody strangely constrained system to disallow Perl, which is as close to a standard Unix utility you can get without making it into SuS. The only *real* motivation I have seen for this is a system that as far I can tell is nothing other than a toy, specifically designed to show off how little you need to build the kernel. In other words, it's not a practical application, it's a show-off art piece. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
Rob Landley wrote: > > You mean "The new shell script is much simpler, about 1/4 the size, runs on > Red Hat 9 from 2003, and isn't perl?" :) > And introduces unclear environment dependencies depending on how external utilities are implemented. The whole point of why that script was written in Perl was to have access to arbitrary-precision arithmetic -- after it was shown that bc would simply lock up on some systems. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH [0/3]: Simplify the kernel build by removing perl.
Theodore Tso wrote: > perl is actually quite portable. Portability aside, Perl has another fun issue. The number of times I've had a Perl script break when copied to a newer system which had a newer version of Perl is... noticable. > I'd also suggest explicitly add a reminder to the shell scripts' > comments to avoid bashisms for maximum portability, to remind > developers in the future who might try to change the shell scripts > to watch out for portability issues. You can force Bash into POSIX mode if that's helpful. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh
On Fri, 2009-01-02 at 06:00 -0600, Rob Landley wrote: > On Friday 02 January 2009 03:04:39 Sam Ravnborg wrote: > > > +# Output start of header file > > > + > > > +cat << EOF > > > +/* Automatically generated by kernel/timeconst.sh */ > > > +/* Conversion constants for HZ == $HZ */ > > > + > > > +#ifndef KERNEL_TIMECONST_H > > > +#define KERNEL_TIMECONST_H > > > > Please use __KERNEL_TIMECONST_H. The two underscores are standard. > > Sure thing. (I was just copying the perl there, I'll post an updated patch > after I get some sleep.) In the x86 discussions recently regarding header guards, I though a single underscore was eventually decided on as 'standard'. Harvey -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
