* [PATCH 0/3] clean out Perl from build system.
@ 2009-12-08 9:17 Rob Landley
2009-12-08 9:19 ` [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley
` (3 more replies)
0 siblings, 4 replies; 47+ messages in thread
From: Rob Landley @ 2009-12-08 9:17 UTC (permalink / raw)
To: linux-kernel
Perl was introduced as a build dependency in 2.6.25. My cross-compile
environment does not use perl, so ever since then I've patched it back out.
With these patches I've personally built kernels for x86, x86_64, arm, mips,
powerpc, sparc, sh4, and m68k.
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply [flat|nested] 47+ messages in thread* [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-08 9:17 [PATCH 0/3] clean out Perl from build system Rob Landley @ 2009-12-08 9:19 ` Rob Landley 2009-12-09 15:45 ` Michal Marek 2009-12-08 9:21 ` [PATCH 2/3] Remove perl from make headers_install Rob Landley ` (2 subsequent siblings) 3 siblings, 1 reply; 47+ messages in thread From: Rob Landley @ 2009-12-08 9:19 UTC (permalink / raw) To: linux-kernel From: Rob Landley <rob@landley.net> 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. Signed-off-by: Rob Landley <rob@landley.net> -- kernel/Makefile | 4 kernel/timeconst.pl | 378 ------------------------------------------ kernel/timeconst.sh | 91 ++++++++++ 3 files changed, 93 insertions(+), 380 deletions(-) diff -ruN linux-2.6.30/kernel/Makefile linux-2.6.30.new/kernel/Makefile --- linux-2.6.30/kernel/Makefile 2009-06-09 22:05:27.000000000 -0500 +++ linux-2.6.30.new/kernel/Makefile 2009-06-22 14:29:16.000000000 -0500 @@ -123,7 +123,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) diff -ruN linux-2.6.30/kernel/timeconst.pl linux-2.6.30.new/kernel/timeconst.pl --- linux-2.6.30/kernel/timeconst.pl 2009-06-09 22:05:27.000000000 -0500 +++ linux-2.6.30.new/kernel/timeconst.pl 1969-12-31 18:00:00.000000000 -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 => [ - '0xa6aaaaab','0x2aaaaaa',26, - 125,3, - '0xc49ba5e4','0x1fbe76c8b4',37, - 3,125, - '0xa2c2aaab','0xaaaa',16, - 125000,3, - '0xc9539b89','0x7fffbce4217d',47, - 3,125000, - ], 32 => [ - '0xfa000000','0x6000000',27, - 125,4, - '0x83126e98','0xfdf3b645a',36, - 4,125, - '0xf4240000','0x0',17, - 31250,1, - '0x8637bd06','0x3fff79c842fa',46, - 1,31250, - ], 48 => [ - '0xa6aaaaab','0x6aaaaaa',27, - 125,6, - '0xc49ba5e4','0xfdf3b645a',36, - 6,125, - '0xa2c2aaab','0x15555',17, - 62500,3, - '0xc9539b89','0x3fffbce4217d',46, - 3,62500, - ], 64 => [ - '0xfa000000','0xe000000',28, - 125,8, - '0x83126e98','0x7ef9db22d',35, - 8,125, - '0xf4240000','0x0',18, - 15625,1, - '0x8637bd06','0x1fff79c842fa',45, - 1,15625, - ], 100 => [ - '0xa0000000','0x0',28, - 10,1, - '0xcccccccd','0x733333333',35, - 1,10, - '0x9c400000','0x0',18, - 10000,1, - '0xd1b71759','0x1fff2e48e8a7',45, - 1,10000, - ], 122 => [ - '0x8325c53f','0xfbcda3a',28, - 500,61, - '0xf9db22d1','0x7fbe76c8b',35, - 61,500, - '0x8012e2a0','0x3ef36',18, - 500000,61, - '0xffda4053','0x1ffffbce4217',45, - 61,500000, - ], 128 => [ - '0xfa000000','0x1e000000',29, - 125,16, - '0x83126e98','0x3f7ced916',34, - 16,125, - '0xf4240000','0x40000',19, - 15625,2, - '0x8637bd06','0xfffbce4217d',44, - 2,15625, - ], 200 => [ - '0xa0000000','0x0',29, - 5,1, - '0xcccccccd','0x333333333',34, - 1,5, - '0x9c400000','0x0',19, - 5000,1, - '0xd1b71759','0xfff2e48e8a7',44, - 1,5000, - ], 250 => [ - '0x80000000','0x0',29, - 4,1, - '0x80000000','0x180000000',33, - 1,4, - '0xfa000000','0x0',20, - 4000,1, - '0x83126e98','0x7ff7ced9168',43, - 1,4000, - ], 256 => [ - '0xfa000000','0x3e000000',30, - 125,32, - '0x83126e98','0x1fbe76c8b',33, - 32,125, - '0xf4240000','0xc0000',20, - 15625,4, - '0x8637bd06','0x7ffde7210be',43, - 4,15625, - ], 300 => [ - '0xd5555556','0x2aaaaaaa',30, - 10,3, - '0x9999999a','0x1cccccccc',33, - 3,10, - '0xd0555556','0xaaaaa',20, - 10000,3, - '0x9d495183','0x7ffcb923a29',43, - 3,10000, - ], 512 => [ - '0xfa000000','0x7e000000',31, - 125,64, - '0x83126e98','0xfdf3b645',32, - 64,125, - '0xf4240000','0x1c0000',21, - 15625,8, - '0x8637bd06','0x3ffef39085f',42, - 8,15625, - ], 1000 => [ - '0x80000000','0x0',31, - 1,1, - '0x80000000','0x0',31, - 1,1, - '0xfa000000','0x0',22, - 1000,1, - '0x83126e98','0x1ff7ced9168',41, - 1,1000, - ], 1024 => [ - '0xfa000000','0xfe000000',32, - 125,128, - '0x83126e98','0x7ef9db22',31, - 128,125, - '0xf4240000','0x3c0000',22, - 15625,16, - '0x8637bd06','0x1fff79c842f',41, - 16,15625, - ], 1200 => [ - '0xd5555556','0xd5555555',32, - 5,6, - '0x9999999a','0x66666666',31, - 6,5, - '0xd0555556','0x2aaaaa',22, - 2500,3, - '0x9d495183','0x1ffcb923a29',41, - 3,2500, - ] -); - -$has_bigint = eval 'use Math::BigInt qw(bgcd); 1;'; - -sub bint($) -{ - my($x) = @_; - return Math::BigInt->new($x); -} - -# -# Constants for division by reciprocal multiplication. -# (bits, numerator, denominator) -# -sub fmul($$$) -{ - my ($b,$n,$d) = @_; - - $n = bint($n); - $d = bint($d); - - return scalar (($n << $b)+$d-bint(1))/$d; -} - -sub fadj($$$) -{ - my($b,$n,$d) = @_; - - $n = bint($n); - $d = bint($d); - - $d = $d/bgcd($n, $d); - return scalar (($d-bint(1)) << $b)/$d; -} - -sub fmuls($$$) { - my($b,$n,$d) = @_; - my($s,$m); - my($thres) = bint(1) << ($b-1); - - $n = bint($n); - $d = bint($d); - - for ($s = 0; 1; $s++) { - $m = fmul($s,$n,$d); - return $s if ($m >= $thres); - } - return 0; -} - -# Generate a hex value if the result fits in 64 bits; -# otherwise skip. -sub bignum_hex($) { - my($x) = @_; - my $s = $x->as_hex(); - - return (length($s) > 18) ? undef : $s; -} - -# Provides mul, adj, and shr factors for a specific -# (bit, time, hz) combination -sub muladj($$$) { - my($b, $t, $hz) = @_; - my $s = fmuls($b, $t, $hz); - my $m = fmul($s, $t, $hz); - my $a = fadj($s, $t, $hz); - return (bignum_hex($m), bignum_hex($a), $s); -} - -# Provides numerator, denominator values -sub numden($$) { - my($n, $d) = @_; - my $g = bgcd($n, $d); - return ($n/$g, $d/$g); -} - -# All values for a specific (time, hz) combo -sub conversions($$) { - my ($t, $hz) = @_; - my @val = (); - - # HZ_TO_xx - push(@val, muladj(32, $t, $hz)); - push(@val, numden($t, $hz)); - - # xx_TO_HZ - push(@val, muladj(32, $hz, $t)); - push(@val, numden($hz, $t)); - - return @val; -} - -sub compute_values($) { - my($hz) = @_; - my @val = (); - my $s, $m, $a, $g; - - if (!$has_bigint) { - die "$0: HZ == $hz not canned and ". - "Math::BigInt not available\n"; - } - - # MSEC conversions - push(@val, conversions(1000, $hz)); - - # USEC conversions - push(@val, conversions(1000000, $hz)); - - return @val; -} - -sub outputval($$) -{ - my($name, $val) = @_; - my $csuf; - - if (defined($val)) { - if ($name !~ /SHR/) { - $val = "U64_C($val)"; - } - printf "#define %-23s %s\n", $name.$csuf, $val.$csuf; - } -} - -sub output($@) -{ - my($hz, @val) = @_; - my $pfx, $bit, $suf, $s, $m, $a; - - print "/* Automatically generated by kernel/timeconst.pl */\n"; - print "/* Conversion constants for HZ == $hz */\n"; - print "\n"; - print "#ifndef KERNEL_TIMECONST_H\n"; - print "#define KERNEL_TIMECONST_H\n"; - print "\n"; - - print "#include <linux/param.h>\n"; - print "#include <linux/types.h>\n"; - - print "\n"; - print "#if HZ != $hz\n"; - print "#error \"kernel/timeconst.h has the wrong HZ value!\"\n"; - print "#endif\n"; - print "\n"; - - foreach $pfx ('HZ_TO_MSEC','MSEC_TO_HZ', - 'HZ_TO_USEC','USEC_TO_HZ') { - foreach $bit (32) { - foreach $suf ('MUL', 'ADJ', 'SHR') { - outputval("${pfx}_$suf$bit", shift(@val)); - } - } - foreach $suf ('NUM', 'DEN') { - outputval("${pfx}_$suf", shift(@val)); - } - } - - print "\n"; - print "#endif /* KERNEL_TIMECONST_H */\n"; -} - -# Pretty-print Perl values -sub perlvals(@) { - my $v; - my @l = (); - - foreach $v (@_) { - if (!defined($v)) { - push(@l, 'undef'); - } elsif ($v =~ /^0x/) { - push(@l, "\'".$v."\'"); - } else { - push(@l, $v.''); - } - } - return join(',', @l); -} - -($hz) = @ARGV; - -# Use this to generate the %canned_values structure -if ($hz eq '--can') { - shift(@ARGV); - @hzlist = sort {$a <=> $b} (@ARGV); - - print "# Precomputed values for systems without Math::BigInt\n"; - print "# Generated by:\n"; - print "# timeconst.pl --can ", join(' ', @hzlist), "\n"; - print "\%canned_values = (\n"; - my $pf = "\t"; - foreach $hz (@hzlist) { - my @values = compute_values($hz); - print "$pf$hz => [\n"; - while (scalar(@values)) { - my $bit; - foreach $bit (32) { - my $m = shift(@values); - my $a = shift(@values); - my $s = shift(@values); - print "\t\t", perlvals($m,$a,$s), ",\n"; - } - my $n = shift(@values); - my $d = shift(@values); - print "\t\t", perlvals($n,$d), ",\n"; - } - print "\t]"; - $pf = ', '; - } - print "\n);\n"; -} else { - $hz += 0; # Force to number - if ($hz < 1) { - die "Usage: $0 HZ\n"; - } - - @val = @{$canned_values{$hz}}; - if (!defined(@val)) { - @val = compute_values($hz); - } - output($hz, @val); -} -exit 0; diff -ruN linux-2.6.30/kernel/timeconst.sh linux-2.6.30.new/kernel/timeconst.sh --- linux-2.6.30/kernel/timeconst.sh 1969-12-31 18:00:00.000000000 -0600 +++ linux-2.6.30.new/kernel/timeconst.sh 2009-06-22 14:29:16.000000000 -0500 @@ -0,0 +1,148 @@ +#!/bin/sh + +if [ $# -ne 2 ] +then + echo "Usage: timeconst.sh HZ FILENAME" + echo + echo "Generate a header file with constants for coverting between" + echo "decimal HZ timer ticks and milisecond or microsecond delays." + echo + exit 1 +fi + +HZ=$1 +shift +FILENAME=$1 + +# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit math. + +if [ $((1 << 32)) -lt 0 ] +then + echo "timeconst.sh needs a shell with 64 bit math, such as bash," + echo "busybox ash, or dash running on a 64 bit host." + exit 1 +fi + +# If this script exits for any reason before this trap is removed, +# delete the output file so a partial file won't confuse the build. + +trap "rm $FILENAME" EXIT + +# Output start of header file + +cat > $FILENAME << EOF || exit 1 +/* Automatically generated by kernel/timeconst.sh */ +/* Conversion constants for HZ == $HZ */ + +#ifndef __KERNEL_TIMECONST_H +#define __KERNEL_TIMECONST_H + +#include <linux/param.h> +#include <linux/types.h> + +#if HZ != $HZ +#error "kernel/timeconst.h has the wrong HZ value!" +#endif + +EOF + +# For both Milliseconds and Microseconds + +cat << EOF | +MSEC 1000 +USEC 1000000 +EOF +while read NAME PERIOD +do + # 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 + + # Calculate 32 significant bits of MUL32 data. + + SHIFT=0 + while true + do + # This can't overflow 64 bit math. Pathological case + # (TO=1, FROM=1000000) uses around 32+20=52 bits. + + MUL32=$(( ( ( $TO << $SHIFT ) + $FROM - 1 ) / $FROM )) + + # Keep increasing $SHIFT until we've got 32 bits. + + [ $MUL32 -gt $(( 1 << 31 )) ] && break + SHIFT=$(( $SHIFT + 1 )) + done + MUL32=$( printf %x $MUL32 ) + + # ADJ32 is just (((FROM/GCD)-1)<<SHIFT)/(FROM/GCD) but this + # can overflow 64 bit math (examples, HZ=24 or HZ=122). + # Pathological case could use 32+20+20=72 bits. (And this is + # the pathological case because a larger $HZ results in a + # smaller $SHIFT, so even insane HZ>USEC cases should be ok.) + + # To get around this, we chop the bottom 32 bits off the + # calculation and then reassemble it to avoid overflow: + # 32+64=96, which is > 72. + + ADJ32=$(( $FROM / $GCD )) + if [ $SHIFT -gt 32 ] + then + UPPER=$(( ( $ADJ32 - 1 ) << ( $SHIFT - 32 ) )) + LOWER=$(( ( $UPPER % $ADJ32 ) << 32 )) + ADJ32=$(( ( ( $UPPER / $ADJ32 ) << 32 ) + ( $LOWER / $ADJ32 ))) + else + ADJ32=$(( ( ( $ADJ32 - 1 ) << $SHIFT) / $ADJ32 )) + fi + ADJ32=$( printf %x $ADJ32 ) + + NUM=$(( $TO / $GCD )) + DEN=$(( $FROM / $GCD )) + + # Output next chunk of header data to file + + ( + echo "#define ${CONVERT}_MUL32 U64_C(0x$MUL32)" && + echo "#define ${CONVERT}_ADJ32 U64_C(0x$ADJ32)" && + echo "#define ${CONVERT}_SHR32 $SHIFT" && + echo "#define ${CONVERT}_NUM U64_C($NUM)" && + echo "#define ${CONVERT}_DEN U64_C($DEN)" + ) >> $FILENAME || exit 1 + done +done + +( + echo + echo "#endif /* __KERNEL_TIMECHONST_H */" +) >> $FILENAME || exit 1 + +# Don't rm $FILENAME on exit anymore. + +trap "" EXIT + +exit 0 -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-08 9:19 ` [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley @ 2009-12-09 15:45 ` Michal Marek 2009-12-09 23:40 ` Rob Landley 0 siblings, 1 reply; 47+ messages in thread From: Michal Marek @ 2009-12-09 15:45 UTC (permalink / raw) To: Rob Landley; +Cc: linux-kernel, H. Peter Anvin, linux-kbuild [CC hpa who wrote the timeconst.pl script] On 8.12.2009 10:19, Rob Landley wrote: > From: Rob Landley <rob@landley.net> > > 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. I tried the shell script with the precomputed values in timeconst.pl and it gave me different results than the perl version for 250 and 1000: with HZ=250: --- perl +++ bash @@ -8,14 +8,14 @@ #error "kernel/timeconst.h has the wrong HZ value!" #endif -#define HZ_TO_MSEC_MUL32 U64_C(0x80000000) +#define HZ_TO_MSEC_MUL32 U64_C(0x100000000) #define HZ_TO_MSEC_ADJ32 U64_C(0x0) -#define HZ_TO_MSEC_SHR32 29 +#define HZ_TO_MSEC_SHR32 30 #define HZ_TO_MSEC_NUM U64_C(4) #define HZ_TO_MSEC_DEN U64_C(1) -#define MSEC_TO_HZ_MUL32 U64_C(0x80000000) -#define MSEC_TO_HZ_ADJ32 U64_C(0x180000000) -#define MSEC_TO_HZ_SHR32 33 +#define MSEC_TO_HZ_MUL32 U64_C(0x100000000) +#define MSEC_TO_HZ_ADJ32 U64_C(0x300000000) +#define MSEC_TO_HZ_SHR32 34 #define MSEC_TO_HZ_NUM U64_C(1) #define MSEC_TO_HZ_DEN U64_C(4) #define HZ_TO_USEC_MUL32 U64_C(0xfa000000) and with HZ=1000: --- perl +++ bash @@ -8,14 +8,14 @@ #error "kernel/timeconst.h has the wrong HZ value!" #endif -#define HZ_TO_MSEC_MUL32 U64_C(0x80000000) +#define HZ_TO_MSEC_MUL32 U64_C(0x100000000) #define HZ_TO_MSEC_ADJ32 U64_C(0x0) -#define HZ_TO_MSEC_SHR32 31 +#define HZ_TO_MSEC_SHR32 32 #define HZ_TO_MSEC_NUM U64_C(1) #define HZ_TO_MSEC_DEN U64_C(1) -#define MSEC_TO_HZ_MUL32 U64_C(0x80000000) +#define MSEC_TO_HZ_MUL32 U64_C(0x100000000) #define MSEC_TO_HZ_ADJ32 U64_C(0x0) -#define MSEC_TO_HZ_SHR32 31 +#define MSEC_TO_HZ_SHR32 32 #define MSEC_TO_HZ_NUM U64_C(1) #define MSEC_TO_HZ_DEN U64_C(1) #define HZ_TO_USEC_MUL32 U64_C(0xfa000000) $ bash --version GNU bash, version 4.0.33(1)-release (x86_64-suse-linux-gnu) ... You're trying to avoid the build dependency on Perl. What about adding a timeconst.h_shipped with the precomputed values from timeconst.pl: #if HZ == 24 #define ... ... #endif #if HZ == 32 ... #endif ... #ifndef HZ_TO_MSEC_MUL32 # error "Unknown HZ value, please update kernel/timeconst.h using kernel/timeconst.pl" #endif plus some makefile automagic to run the script iff the HZ value isn't precomputed. Then you would only need Perl for exotic HZ configurations. > > Signed-off-by: Rob Landley <rob@landley.net> > -- > > kernel/Makefile | 4 > kernel/timeconst.pl | 378 ------------------------------------------ > kernel/timeconst.sh | 91 ++++++++++ > 3 files changed, 93 insertions(+), 380 deletions(-) > > diff -ruN linux-2.6.30/kernel/Makefile linux-2.6.30.new/kernel/Makefile > --- linux-2.6.30/kernel/Makefile 2009-06-09 22:05:27.000000000 -0500 > +++ linux-2.6.30.new/kernel/Makefile 2009-06-22 14:29:16.000000000 -0500 > @@ -123,7 +123,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) > diff -ruN linux-2.6.30/kernel/timeconst.pl linux-2.6.30.new/kernel/timeconst.pl > --- linux-2.6.30/kernel/timeconst.pl 2009-06-09 22:05:27.000000000 -0500 > +++ linux-2.6.30.new/kernel/timeconst.pl 1969-12-31 18:00:00.000000000 -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 [snip] > diff -ruN linux-2.6.30/kernel/timeconst.sh linux-2.6.30.new/kernel/timeconst.sh > --- linux-2.6.30/kernel/timeconst.sh 1969-12-31 18:00:00.000000000 -0600 > +++ linux-2.6.30.new/kernel/timeconst.sh 2009-06-22 14:29:16.000000000 -0500 > @@ -0,0 +1,148 @@ > +#!/bin/sh > + > +if [ $# -ne 2 ] > +then > + echo "Usage: timeconst.sh HZ FILENAME" > + echo > + echo "Generate a header file with constants for coverting between" > + echo "decimal HZ timer ticks and milisecond or microsecond delays." > + echo > + exit 1 > +fi > + > +HZ=$1 > +shift > +FILENAME=$1 > + > +# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit math. > + > +if [ $((1 << 32)) -lt 0 ] > +then > + echo "timeconst.sh needs a shell with 64 bit math, such as bash," > + echo "busybox ash, or dash running on a 64 bit host." > + exit 1 > +fi > + > +# If this script exits for any reason before this trap is removed, > +# delete the output file so a partial file won't confuse the build. > + > +trap "rm $FILENAME" EXIT > + > +# Output start of header file > + > +cat > $FILENAME << EOF || exit 1 > +/* Automatically generated by kernel/timeconst.sh */ > +/* Conversion constants for HZ == $HZ */ > + > +#ifndef __KERNEL_TIMECONST_H > +#define __KERNEL_TIMECONST_H > + > +#include <linux/param.h> > +#include <linux/types.h> > + > +#if HZ != $HZ > +#error "kernel/timeconst.h has the wrong HZ value!" > +#endif > + > +EOF > + > +# For both Milliseconds and Microseconds > + > +cat << EOF | > +MSEC 1000 > +USEC 1000000 > +EOF > +while read NAME PERIOD > +do > + # 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 > + > + # Calculate 32 significant bits of MUL32 data. > + > + SHIFT=0 > + while true > + do > + # This can't overflow 64 bit math. Pathological case > + # (TO=1, FROM=1000000) uses around 32+20=52 bits. > + > + MUL32=$(( ( ( $TO << $SHIFT ) + $FROM - 1 ) / $FROM )) > + > + # Keep increasing $SHIFT until we've got 32 bits. > + > + [ $MUL32 -gt $(( 1 << 31 )) ] && break > + SHIFT=$(( $SHIFT + 1 )) > + done > + MUL32=$( printf %x $MUL32 ) > + > + # ADJ32 is just (((FROM/GCD)-1)<<SHIFT)/(FROM/GCD) but this > + # can overflow 64 bit math (examples, HZ=24 or HZ=122). > + # Pathological case could use 32+20+20=72 bits. (And this is > + # the pathological case because a larger $HZ results in a > + # smaller $SHIFT, so even insane HZ>USEC cases should be ok.) > + > + # To get around this, we chop the bottom 32 bits off the > + # calculation and then reassemble it to avoid overflow: > + # 32+64=96, which is > 72. > + > + ADJ32=$(( $FROM / $GCD )) > + if [ $SHIFT -gt 32 ] > + then > + UPPER=$(( ( $ADJ32 - 1 ) << ( $SHIFT - 32 ) )) > + LOWER=$(( ( $UPPER % $ADJ32 ) << 32 )) > + ADJ32=$(( ( ( $UPPER / $ADJ32 ) << 32 ) + ( $LOWER / $ADJ32 ))) > + else > + ADJ32=$(( ( ( $ADJ32 - 1 ) << $SHIFT) / $ADJ32 )) > + fi > + ADJ32=$( printf %x $ADJ32 ) > + > + NUM=$(( $TO / $GCD )) > + DEN=$(( $FROM / $GCD )) > + > + # Output next chunk of header data to file > + > + ( > + echo "#define ${CONVERT}_MUL32 U64_C(0x$MUL32)" && > + echo "#define ${CONVERT}_ADJ32 U64_C(0x$ADJ32)" && > + echo "#define ${CONVERT}_SHR32 $SHIFT" && > + echo "#define ${CONVERT}_NUM U64_C($NUM)" && > + echo "#define ${CONVERT}_DEN U64_C($DEN)" > + ) >> $FILENAME || exit 1 > + done > +done > + > +( > + echo > + echo "#endif /* __KERNEL_TIMECHONST_H */" ^ Should be "__KERNEL_TIMECONST_H". > +) >> $FILENAME || exit 1 > + > +# Don't rm $FILENAME on exit anymore. > + > +trap "" EXIT > + > +exit 0 > Michal ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-09 15:45 ` Michal Marek @ 2009-12-09 23:40 ` Rob Landley 2009-12-09 23:45 ` H. Peter Anvin 2009-12-10 13:52 ` Michal Marek 0 siblings, 2 replies; 47+ messages in thread From: Rob Landley @ 2009-12-09 23:40 UTC (permalink / raw) To: Michal Marek; +Cc: linux-kernel, H. Peter Anvin, linux-kbuild On Wednesday 09 December 2009 09:45:37 Michal Marek wrote: > [CC hpa who wrote the timeconst.pl script] > > On 8.12.2009 10:19, Rob Landley wrote: > > From: Rob Landley <rob@landley.net> > > > > 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. > > I tried the shell script with the precomputed values in timeconst.pl and > it gave me different results than the perl version for 250 and 1000: You're right. They're functionally equivalent (due to the relationship between MUL32 and SHR32), which is why this code has worked for me and other people for a year now. The difference is the possibility of an integer overflow if you try to convert a time period of "0xffffffff". Trivial fix: --- a/sources/patches/linux-2.6.25-rc1-noperl.patch Tue Dec 08 20:22:53 2009 -0600 +++ b/sources/patches/linux-2.6.25-rc1-noperl.patch Wed Dec 09 17:28:26 2009 -0600 @@ -507,7 +507,7 @@ + + # Keep increasing $SHIFT until we've got 32 bits. + -+ [ $MUL32 -gt $(( 1 << 31 )) ] && break ++ [ $MUL32 -ge $(( 1 << 31 )) ] && break + SHIFT=$(( $SHIFT + 1 )) + done + MUL32=$( printf %x $MUL32 ) As long as MUL32 fits in 32 bits than you can multiply it by another 32 bit number without overflow, and that's probably all the kernel's enforcing. > #define HZ_TO_MSEC_NUM U64_C(4) > #define HZ_TO_MSEC_DEN U64_C(1) > -#define MSEC_TO_HZ_MUL32 U64_C(0x80000000) > -#define MSEC_TO_HZ_ADJ32 U64_C(0x180000000) > -#define MSEC_TO_HZ_SHR32 33 > +#define MSEC_TO_HZ_MUL32 U64_C(0x100000000) > +#define MSEC_TO_HZ_ADJ32 U64_C(0x300000000) > +#define MSEC_TO_HZ_SHR32 34 > #define MSEC_TO_HZ_NUM U64_C(1) > #define MSEC_TO_HZ_DEN U64_C(4) > #define HZ_TO_USEC_MUL32 U64_C(0xfa000000) The same. > and with HZ=1000: > --- perl > +++ bash > @@ -8,14 +8,14 @@ > #error "kernel/timeconst.h has the wrong HZ value!" > #endif > > -#define HZ_TO_MSEC_MUL32 U64_C(0x80000000) > +#define HZ_TO_MSEC_MUL32 U64_C(0x100000000) > #define HZ_TO_MSEC_ADJ32 U64_C(0x0) > -#define HZ_TO_MSEC_SHR32 31 > +#define HZ_TO_MSEC_SHR32 32 And again. > #define HZ_TO_MSEC_NUM U64_C(1) > #define HZ_TO_MSEC_DEN U64_C(1) > -#define MSEC_TO_HZ_MUL32 U64_C(0x80000000) > +#define MSEC_TO_HZ_MUL32 U64_C(0x100000000) > #define MSEC_TO_HZ_ADJ32 U64_C(0x0) > -#define MSEC_TO_HZ_SHR32 31 > +#define MSEC_TO_HZ_SHR32 32 Same thing. > You're trying to avoid the build dependency on Perl. What about adding a > timeconst.h_shipped with the precomputed values from timeconst.pl: Been there, done that. My first patch (way back for 2.6.25) took that approach: http://landley.net/hg/hgwebdir.cgi/firmware/file/a791ca629d9c/sources/patches/linux-2.6.25- rc1-noperl.patch But it turns out various non-x86 targets (such as ARM OMAP) allow HZ to be specified by an entry field in the config file, into which the user can type a range of numbers. See this post from last year for details: http://lists.impactlinux.com/pipermail/firmware-impactlinux.com/2008- December/000022.html This is why reducing the perl version to just the precomputed constants wouldn't work either. (They're there so that you only need to install a random cpan library when surprised by a build break on non-x86 machines.) > > + echo > > + echo "#endif /* __KERNEL_TIMECHONST_H */" > > ^ > > Should be "__KERNEL_TIMECONST_H". Yeah, Joe Perches pointed that out to me off-list. It's just a comment so I didn't resubmit the patch for that, but I've fixed my local version already. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-09 23:40 ` Rob Landley @ 2009-12-09 23:45 ` H. Peter Anvin 2009-12-10 1:50 ` Rob Landley 2009-12-10 13:52 ` Michal Marek 1 sibling, 1 reply; 47+ messages in thread From: H. Peter Anvin @ 2009-12-09 23:45 UTC (permalink / raw) To: Rob Landley; +Cc: Michal Marek, linux-kernel, linux-kbuild On 12/09/2009 03:40 PM, Rob Landley wrote: > > This is why reducing the perl version to just the precomputed constants > wouldn't work either. (They're there so that you only need to install a > random cpan library when surprised by a build break on non-x86 machines.) > It's not "a random CPAN library" - it's a core module. -hpa ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-09 23:45 ` H. Peter Anvin @ 2009-12-10 1:50 ` Rob Landley 2009-12-10 1:53 ` H. Peter Anvin 0 siblings, 1 reply; 47+ messages in thread From: Rob Landley @ 2009-12-10 1:50 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Michal Marek, linux-kernel, linux-kbuild On Wednesday 09 December 2009 17:45:21 H. Peter Anvin wrote: > On 12/09/2009 03:40 PM, Rob Landley wrote: > > This is why reducing the perl version to just the precomputed constants > > wouldn't work either. (They're there so that you only need to install a > > random cpan library when surprised by a build break on non-x86 machines.) > > It's not "a random CPAN library" - it's a core module. Then why cache large quantities of its output and test for its existence? Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-10 1:50 ` Rob Landley @ 2009-12-10 1:53 ` H. Peter Anvin 0 siblings, 0 replies; 47+ messages in thread From: H. Peter Anvin @ 2009-12-10 1:53 UTC (permalink / raw) To: Rob Landley; +Cc: Michal Marek, linux-kernel, linux-kbuild On 12/09/2009 05:50 PM, Rob Landley wrote: > On Wednesday 09 December 2009 17:45:21 H. Peter Anvin wrote: >> On 12/09/2009 03:40 PM, Rob Landley wrote: >>> This is why reducing the perl version to just the precomputed constants >>> wouldn't work either. (They're there so that you only need to install a >>> random cpan library when surprised by a build break on non-x86 machines.) >> >> It's not "a random CPAN library" - it's a core module. > > Then why cache large quantities of its output and test for its existence? > To support archaic Perl versions and Perl binaries without libraries. -hpa ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-09 23:40 ` Rob Landley 2009-12-09 23:45 ` H. Peter Anvin @ 2009-12-10 13:52 ` Michal Marek 2009-12-10 23:16 ` Rob Landley 1 sibling, 1 reply; 47+ messages in thread From: Michal Marek @ 2009-12-10 13:52 UTC (permalink / raw) To: Rob Landley; +Cc: linux-kernel, H. Peter Anvin, linux-kbuild On 10.12.2009 00:40, Rob Landley wrote: > On Wednesday 09 December 2009 09:45:37 Michal Marek wrote: >> You're trying to avoid the build dependency on Perl. What about adding a >> timeconst.h_shipped with the precomputed values from timeconst.pl: > > Been there, done that. My first patch (way back for 2.6.25) took that > approach: > > http://landley.net/hg/hgwebdir.cgi/firmware/file/a791ca629d9c/sources/patches/linux-2.6.25- > rc1-noperl.patch > > But it turns out various non-x86 targets (such as ARM OMAP) allow HZ to be > specified by an entry field in the config file, into which the user can type a > range of numbers. See this post from last year for details: > > http://lists.impactlinux.com/pipermail/firmware-impactlinux.com/2008- > December/000022.html > > This is why reducing the perl version to just the precomputed constants > wouldn't work either. (They're there so that you only need to install a > random cpan library when surprised by a build break on non-x86 machines.) That's why I wrote >> plus some makefile automagic to run the script iff the HZ value isn't >> precomputed. Then you would only need Perl for exotic HZ configurations. E.g. make it ... #elif HZ == 1200 ... #else #include "timeconst_custom.h" #endif and the makefile would run timeconst.pl to generate timeconst_custom.h iff HZ is set to something arbitrary. I don't have a patch for that, but I don't see a fundamental problem with such approach. Michal ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-10 13:52 ` Michal Marek @ 2009-12-10 23:16 ` Rob Landley 2009-12-11 15:31 ` Michal Marek 0 siblings, 1 reply; 47+ messages in thread From: Rob Landley @ 2009-12-10 23:16 UTC (permalink / raw) To: Michal Marek; +Cc: linux-kernel, H. Peter Anvin, linux-kbuild On Thursday 10 December 2009 07:52:44 Michal Marek wrote: > On 10.12.2009 00:40, Rob Landley wrote: > > On Wednesday 09 December 2009 09:45:37 Michal Marek wrote: > >> You're trying to avoid the build dependency on Perl. What about adding a > >> timeconst.h_shipped with the precomputed values from timeconst.pl: > > > > Been there, done that. My first patch (way back for 2.6.25) took that > > approach: > > > > http://landley.net/hg/hgwebdir.cgi/firmware/file/a791ca629d9c/sources/pat > >ches/linux-2.6.25- rc1-noperl.patch > > > > But it turns out various non-x86 targets (such as ARM OMAP) allow HZ to > > be specified by an entry field in the config file, into which the user > > can type a range of numbers. See this post from last year for details: > > > > http://lists.impactlinux.com/pipermail/firmware-impactlinux.com/2008- > > December/000022.html > > > > This is why reducing the perl version to just the precomputed constants > > wouldn't work either. (They're there so that you only need to install a > > random cpan library when surprised by a build break on non-x86 machines.) > > That's why I wrote > > >> plus some makefile automagic to run the script iff the HZ value isn't > >> precomputed. Then you would only need Perl for exotic HZ configurations. > > E.g. make it > ... > #elif HZ == 1200 > ... > #else > #include "timeconst_custom.h" > #endif > > and the makefile would run timeconst.pl to generate timeconst_custom.h > iff HZ is set to something arbitrary. I don't have a patch for that, but > I don't see a fundamental problem with such approach. I looked at that when I was attempting to update (rather than replace) my original patch. There's a reason I didn't go there. You're suggesting there be two code paths, one maintained by hand and the other just about never tested against bit-rot. You want to add logic to the makefile so it knows when to run the perl script and when not to, meaning the makefile needs its own list of the cached HZ values, which needs to be kept in sync with the header of cached values, and thus the same information has to live in two places. Meanwhile the shell script exists, works, and takes a fraction of a second to run. Using it every build provides a single consistent code path which works the same for everybody. I'm not seeing any advantage in cacheing values that are easy to calculate at compile time. It's just as easy to completely eliminate the perl dependency as to merely mitigate it. > Michal Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-10 23:16 ` Rob Landley @ 2009-12-11 15:31 ` Michal Marek 2009-12-11 19:13 ` H. Peter Anvin 0 siblings, 1 reply; 47+ messages in thread From: Michal Marek @ 2009-12-11 15:31 UTC (permalink / raw) To: Rob Landley; +Cc: linux-kernel, H. Peter Anvin, linux-kbuild Rob Landley wrote: > On Thursday 10 December 2009 07:52:44 Michal Marek wrote: >> and the makefile would run timeconst.pl to generate timeconst_custom.h >> iff HZ is set to something arbitrary. I don't have a patch for that, but >> I don't see a fundamental problem with such approach. > > I looked at that when I was attempting to update (rather than replace) my > original patch. There's a reason I didn't go there. You're suggesting there > be two code paths, one maintained by hand and the other just about never > tested against bit-rot. OK, that's valid point, indeed. Peter, would you ack Rob's patch with the oneline fix added (http://lkml.org/lkml/2009/12/8/94 plus http://lkml.org/lkml/2009/12/9/435)? Michal ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-11 15:31 ` Michal Marek @ 2009-12-11 19:13 ` H. Peter Anvin 2009-12-12 0:49 ` Rob Landley 0 siblings, 1 reply; 47+ messages in thread From: H. Peter Anvin @ 2009-12-11 19:13 UTC (permalink / raw) To: Michal Marek; +Cc: Rob Landley, linux-kernel, linux-kbuild On 12/11/2009 07:31 AM, Michal Marek wrote: > > OK, that's valid point, indeed. Peter, would you ack Rob's patch with > the oneline fix added (http://lkml.org/lkml/2009/12/8/94 plus > http://lkml.org/lkml/2009/12/9/435)? > I strongly dislike his patch, as he open-codes specific multiprecision arithmetic. This makes it hard for other people to maintain, and makes it prone to errors -- as evidenced by the fact that it didn't even replicate the known-good results. I have made my position clear on this and other patches several times before: I consider it a fool's errand, and a result of a completely pointless crusade to make a particular science fair-type project a wee bit easier. We have already seen real damage caused by it, since people have used awk instead, and have gotten bitten by incompatibilities between awk implementations. As such, no, I will not ack this patch, and will consider myself released of any obligation to maintain the code if this goes in anyway. I would consider acking a C program which does proper multiprecision arithmetic, but I'm also not going to spend my time on it. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-12-11 19:13 ` H. Peter Anvin @ 2009-12-12 0:49 ` Rob Landley 0 siblings, 0 replies; 47+ messages in thread From: Rob Landley @ 2009-12-12 0:49 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Michal Marek, linux-kernel, linux-kbuild On Friday 11 December 2009 13:13:39 H. Peter Anvin wrote: > On 12/11/2009 07:31 AM, Michal Marek wrote: > > OK, that's valid point, indeed. Peter, would you ack Rob's patch with > > the oneline fix added (http://lkml.org/lkml/2009/12/8/94 plus > > http://lkml.org/lkml/2009/12/9/435)? > > I strongly dislike his patch, as he open-codes specific multiprecision > arithmetic. This makes it hard for other people to maintain, and makes > it prone to errors It's always easier to understand code that you wrote, doubly so with perl. The perl code this is replacing has comments, function names like fmul() and fmuls() with no way to distinguish what they do except by reading their implementation, and half of it is devoting to cacheing the output of the other half for reasons which are never explained in the code. The few comments the perl code does have are sometimes actually misleading. For example, bignum_hex() has the comment "generate a hex value if the result fits in 64 bits; otherwise skip". What would skpping mean in this context? Would it silently emit a broken header, or would it break the build? (My first guess is that "undef" without an expr would be a build break, but maybe this is perl's way of saying "None"? I do know that whatever happened the result wouldn't be a usable kernel, so "skip" is disingenous.) That said, I read through and managed to understand the perl code. But it took me more than a day, and I was motivated by the desire to replace it. > -- as evidenced by the fact that it didn't even > replicate the known-good results. Actually I had noticed the difference back at the time I wrote the script, but the value plus shift were functionally equivalent, and at the time (a year ago) I vaguely recall working through the math (and looking at the kernel code using the output) convinced me that that integer overflow couldn't actually happen for real inputs. But I don't remember why (perhaps the value to be converted is range checked somewhere so ffffffff couldn't actually make it to this code, I don't remember) and thus my version would give more precision to the result (which seemed to be the whole point of the exercise). No point in trying to reconstruct my reasoning from a year ago when it's a one line change to make it non-controversial, and the "value always fits in 32 bits so you can safely multiply by an unsigned int due to LP64" is easier to explain/document anyway. (On the other end of things, I do remember that the admittedly insane HZ of ffffffff would have a GCD of 5 with 1000 and thus not be saved as that. That came up because I was worried an ffffffff value times ffffffff might _round_ up to overflow when adj32 was added. I did attempt to document some of the edge cases in the shell script comments...) > I have made my position clear on this and other patches several times > before: I consider it a fool's errand, I.E. your fundamental objection is to removing perl form the build. You are the one who added this perl to the build system. You're also the one who added perl to all the other projects you maintain (klibc and syslinux I noticed) at approximately the same time, after years of those not requiring perl. I don't know why you suddenly decided perl needed to be everywhere, but the Linux kernel is not the only project you simultaneously applied this philosophy to. I strongly suspect the other objections you've raised in the past two years are a proxy for the objection to removing perl. However, your central objection to removing perl hasn't convinced people like Alan Cox, who called Perl "a bad candidate for our toolchain dependencies" here: http://lkml.indiana.edu/hypermail/linux/kernel/0901.1/02108.html Thus you raise other issues, which seem to be proxies for that fundamental objection. I've tried to address the ones that look like they were actually intended to be addressed, but I note that your current objection is to the something like the seventh submission of this patch, and I believe this is the first time you've raised this particular issue. I believe I first submitted an ancestor of this patch on February 15, 2008. Just this year I've submitted previous versions of this patch (more or less in its current form) on January 2, 2009 (with a resubmit on January 3 in response to feedback), on June 22, and on September 18. And again now. The patch hasn't changed much, your objections to it have. I don't even remember you previously complaining about the output differing. (At a guess, you never actually tried my patch?) But it has been a while, I could easily be forgetting details by now. I'm posting these here because they're useful to other people, not because I expect you to ever stop objecting to them no matter what changes I make. You've made it clear you object to the _goal_ of the patch. The implementation seems to be a side issue. > and a result of a completely > pointless crusade to make a particular science fair-type project a wee > bit easier. Embedded developers' desire to restrict their build environment to something controllable seems to strike you as weird, yes. Would it help to explain that it's the same general theory behind Linux From Scratch making a temporary system, chrooting into it, and then building in there in Chapter 5? Leaking random crap from the host is bad, often in subtle ways you don't immediately catch. Some programs (perl, libtool, syscfg) are champions at leaking context, and to be avoided if at all possible. (I suppose you could always suggest setting up a different build environment for the kernel as for userspace, the way Red Hat used to do with kgcc. Doesn't strike me as a good idea, though.) > We have already seen real damage caused by it, since people > have used awk instead, and have gotten bitten by incompatibilities > between awk implementations. I'm not using AWK, and I'm sticking with POSIX shell constructs that were there in susv3, let alone susv4. Since I wasn't the one proposing any patches extensively using awk (I need the man page open to make awk do anything more complicated than '{print $2}'), and this patch isn't using awk at all, I guess you're once again objecting to the removal of perl in general, not to the patch in front of you. And in doing so, you're providing evidence that I'm not the only one motivated to submit perl removal patches, which might undermine your "particular science fair project" argument a bit. I am motivated to follow up on this. I've been maintaining perl removal patches for a couple years now because I personally need them, but I'm not the only one using these patches, and I've been thanked for tackling this problem by a dozen embedded developers. I wasn't the one who first noticed the perl dependency when it went in back in .25, David Anders notified me of the issue before I'd tested the -rc that introduced it. The most recent guy to say, and I quote, "Thanks for eliminating the perl dependency." to me in private email was Joe Perches (on Tuesday). Embedded developers tend to do stuff off-list. This is because every new kernel breaks random stuff on non-x86 targets. For example, I finally got powerpc's pmac_zilog fixed a few days ago (allowing me to use the serial console on qemu's mac99 target), after a thread stretching back two months (it broke after 2.6.28). The "works for me" fix is here: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078700.html The most recent arm breakage turned out to be simple (a new CONFIG_MMU symbol showed up between 2.6.31 and 2.6.32 and needed to be switched on), but diagnosing "it doesn't boot, no console messages" is always a pain. The most recent mips breakage was fixed by commit d71789b6fa37c21ce5eb588d279f57904a62e7e2 which I asked to be backported to 2.6.31 in the stable series and Greg KH acknowledged on November 5th. (I'd link to my submission to stable@kernel.org but there's no entry for that in vger lists and googling doesn't seem to come up with a public archive.) That's just in the past month or so. Trying to git bisect each of those problems found huge ranges of "it doesn't even compile" in the repository, because that's the _norm_ for non-x86 targets during development. Most embedded developers don't want to deal with this, so they stay a year or three behind the bleeding edge and only upgrade after crazy people like me have gotten it working. Since even the ones who _don't_ start their messages by apologizing about their English know they'll be flamed or ignored if they raise an issue about an 18 month old kernel here, they develop a fear of posting on linux-kernel at all because it's an "unfriendly" place. (I try to talk them out of it, but it's a cultural thing at this point. The new kernel embedded list hasn't really helped more than 10% of this problem.) I regularly tackle these issues anyway, am generally friendly to newbies on the lists I follow, and apparently have no shame, so people sometimes forward issues to me and hope I'll push them upstream so they don't have to. (And then go away again once they've managed to upgrade to whatever snapshot they'll be using for the next 3 years, leaving me to follow up.) *shrug* I'm used to it. You feed stray issues patches and they wind up adopting you... > As such, no, I will not ack this patch, and will consider myself > released of any obligation to maintain the code if this goes in anyway. I've been maintaining this patch series for 2 years already. I would be happy to maintain my changed version in future if it gets in. I expected that. > I would consider acking a C program which does proper multiprecision > arithmetic, but I'm also not going to spend my time on it. Hmmm, "would consider acking" (not "would ack", not even "could ack"), with the additional caveat that the multiprecision arithmetic must be an unspecified "proper", whatever that means. The "proxy objections" thesis stated above would label this an obvious delaying tactic, but if I promise to call your bluff, then the current patch gets dropped on the floor for another development cycle... Well played, sir. I must plead the 5th for now. > -hpa Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH 2/3] Remove perl from make headers_install 2009-12-08 9:17 [PATCH 0/3] clean out Perl from build system Rob Landley 2009-12-08 9:19 ` [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley @ 2009-12-08 9:21 ` Rob Landley 2009-12-08 9:22 ` [PATCH 3/3] Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh Rob Landley 2009-12-08 10:23 ` [PATCH 0/3] clean out Perl from build system Michal Marek 3 siblings, 0 replies; 47+ messages in thread From: Rob Landley @ 2009-12-08 9:21 UTC (permalink / raw) To: linux-kernel From: Rob Landley <rob@landley.net> 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. Signed-off-by: Rob Landley <rob@landley.net> --- scripts/Makefile.headersinst | 6 ++-- scripts/headers_install.pl | 49 --------------------------------- scripts/headers_install.sh | 39 ++++++++++++++++++++++++++ 3 files changed, 42 insertions(+), 52 deletions(-) diff -ruN linux-2.6.30.old/scripts/headers_install.pl linux-2.6.30/scripts/headers_install.pl --- linux-2.6.30.old/scripts/headers_install.pl 2009-06-09 22:05:27.000000000 -0500 +++ linux-2.6.30/scripts/headers_install.pl 1969-12-31 18:00:00.000000000 -0600 @@ -1,49 +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__ -D__EXPORTED_HEADERS__"; - -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 = <INFILE>) { - $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 <linux\/compiler.h>//; - $line =~ s/(^|\s)(inline)\b/$1__$2__/g; - $line =~ s/(^|\s)(asm)\b(\s|[(]|$)/$1__$2__$3/g; - $line =~ s/(^|\s|[(])(volatile)\b(\s|[(]|$)/$1__$2__$3/g; - printf OUTFILE "%s", $line; - } - close OUTFILE; - close INFILE; - system $unifdef . " $tmpfile > $installdir/$file"; - unlink $tmpfile; -} -exit 0; diff -ruN linux-2.6.30.old/scripts/headers_install.sh linux-2.6.30/scripts/headers_install.sh --- linux-2.6.30.old/scripts/headers_install.sh 1969-12-31 18:00:00.000000000 -0600 +++ linux-2.6.30/scripts/headers_install.sh 2009-06-22 16:21:23.000000000 -0500 @@ -0,0 +1,39 @@ +#!/bin/sh + +if [ $# -lt 2 ] +then + echo "Usage: headers_install.sh INDIR OUTDIR [FILES...] + echo + echo "Prepares kernel header files for use by user space, by removing" + echo "all compiler.h definitions and #includes, removing any" + echo "#ifdef __KERNEL__ sections, and putting __underscores__ around" + echo "asm/inline/volatile keywords." + echo + echo "INDIR: directory to read each kernel header FILE from." + echo "OUTDIR: directory to write each userspace header FILE to." + echo "FILES: list of header files to operate on." + + exit 1 +fi + +# Grab arguments + +INDIR="$1" +shift +OUTDIR="$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 <linux/compiler.h>@@' \ + -e 's/(^|[ \t])(inline|asm|volatile)([ \t(]|$)/\1__\2__\3/g' \ + "$INDIR/$i" | + scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ - > "$OUTDIR/$i" +done + +exit 0 diff -ruN linux-2.6.30.old/scripts/Makefile.headersinst linux-2.6.30/scripts/Makefile.headersinst --- linux-2.6.30.old/scripts/Makefile.headersinst 2009-06-09 22:05:27.000000000 -0500 +++ linux-2.6.30/scripts/Makefile.headersinst 2009-06-22 16:21:23.000000000 -0500 @@ -46,8 +46,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) $(header-y); \ + $(CONFIG_SHELL) $< $(objtree)/$(obj) $(install) $(objhdr-y); \ touch $@ quiet_cmd_remove = REMOVE $(unwanted) @@ -70,7 +70,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) -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH 3/3] Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh 2009-12-08 9:17 [PATCH 0/3] clean out Perl from build system Rob Landley 2009-12-08 9:19 ` [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley 2009-12-08 9:21 ` [PATCH 2/3] Remove perl from make headers_install Rob Landley @ 2009-12-08 9:22 ` Rob Landley 2009-12-08 10:23 ` [PATCH 0/3] clean out Perl from build system Michal Marek 3 siblings, 0 replies; 47+ messages in thread From: Rob Landley @ 2009-12-08 9:22 UTC (permalink / raw) To: linux-kernel From: Rob Landley <rob@landley.net> Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh. This script generates kernel/cpu/capflags.c from include/asm/cpufeature.h. Signed-off-by: Rob Landley <rob@landley.net> --- 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 linux-2.6.30.old/arch/x86/kernel/cpu/Makefile linux-2.6.30/arch/x86/kernel/cpu/Makefile --- linux-2.6.30.old/arch/x86/kernel/cpu/Makefile 2009-06-09 22:05:27.000000000 -0500 +++ linux-2.6.30/arch/x86/kernel/cpu/Makefile 2009-06-22 16:39:06.000000000 -0500 @@ -36,10 +36,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 linux-2.6.30.old/arch/x86/kernel/cpu/mkcapflags.pl linux-2.6.30/arch/x86/kernel/cpu/mkcapflags.pl --- linux-2.6.30.old/arch/x86/kernel/cpu/mkcapflags.pl 2009-06-09 22:05:27.000000000 -0500 +++ linux-2.6.30/arch/x86/kernel/cpu/mkcapflags.pl 1969-12-31 18:00:00.000000000 -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 <asm/cpufeature.h>\n\n"; -print OUT "const char * const x86_cap_flags[NCAPINTS*32] = {\n"; - -while (defined($line = <IN>)) { - 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 linux-2.6.30.old/arch/x86/kernel/cpu/mkcapflags.sh linux-2.6.30/arch/x86/kernel/cpu/mkcapflags.sh --- linux-2.6.30.old/arch/x86/kernel/cpu/mkcapflags.sh 1969-12-31 18:00:00.000000000 -0600 +++ linux-2.6.30/arch/x86/kernel/cpu/mkcapflags.sh 2009-06-22 16:39:06.000000000 -0500 @@ -0,0 +1,28 @@ +#!/bin/sh +# +# Generate the x86_cap_flags[] array from include/asm/cpufeature.h +# + +IN=$1 +OUT=$2 + +( + echo "#include <asm/cpufeature.h>" + 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@.*/\* *\("[^"]*"\).*\*/@\1@p')" + [ -z "$VALUE" ] && VALUE="\"$(echo "$NAME" | tr A-Z a-z)\"" + + [ "$VALUE" != '""' ] && echo " [X86_FEATURE_$NAME] = $VALUE," + done + echo "};" +) > $OUT -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 0/3] clean out Perl from build system. 2009-12-08 9:17 [PATCH 0/3] clean out Perl from build system Rob Landley ` (2 preceding siblings ...) 2009-12-08 9:22 ` [PATCH 3/3] Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh Rob Landley @ 2009-12-08 10:23 ` Michal Marek 2009-12-08 15:08 ` Rob Landley 3 siblings, 1 reply; 47+ messages in thread From: Michal Marek @ 2009-12-08 10:23 UTC (permalink / raw) To: Rob Landley; +Cc: linux-kernel, linux-kbuild On 8.12.2009 10:17, Rob Landley wrote: > Perl was introduced as a build dependency in 2.6.25. My cross-compile > environment does not use perl, so ever since then I've patched it back out. > > With these patches I've personally built kernels for x86, x86_64, arm, mips, > powerpc, sparc, sh4, and m68k. Hi Rob, you should CC linux-kbuild@ on patches like this (added now, the whole series is at http://lkml.org/lkml/2009/12/8/93). Michal ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 0/3] clean out Perl from build system. 2009-12-08 10:23 ` [PATCH 0/3] clean out Perl from build system Michal Marek @ 2009-12-08 15:08 ` Rob Landley 0 siblings, 0 replies; 47+ messages in thread From: Rob Landley @ 2009-12-08 15:08 UTC (permalink / raw) To: Michal Marek; +Cc: linux-kernel, linux-kbuild On Tuesday 08 December 2009 04:23:06 Michal Marek wrote: > On 8.12.2009 10:17, Rob Landley wrote: > > Perl was introduced as a build dependency in 2.6.25. My cross-compile > > environment does not use perl, so ever since then I've patched it back > > out. > > > > With these patches I've personally built kernels for x86, x86_64, arm, > > mips, powerpc, sparc, sh4, and m68k. > > Hi Rob, > > you should CC linux-kbuild@ on patches like this (added now, the whole > series is at http://lkml.org/lkml/2009/12/8/93). > > Michal Thanks. LWN said Sam Ravnborg was stepping down, and I haven't kept up with who's in charge now. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH 0/3] Perl removal patches for 2.6.31 @ 2009-09-19 1:25 Rob Landley 2009-09-19 1:33 ` [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley 0 siblings, 1 reply; 47+ messages in thread From: Rob Landley @ 2009-09-19 1:25 UTC (permalink / raw) To: kernel list Perl dependencies were introduced into the build system in 2.6.25. This removes the central ones preventing a bootable kernel from building without perl. For the record, the perl removal patches I submitted for 2.6.30, still work fine (they apply with offsets). Here are versions that apply without offsets to 2.6.31. Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-09-19 1:25 [PATCH 0/3] Perl removal patches for 2.6.31 Rob Landley @ 2009-09-19 1:33 ` Rob Landley 0 siblings, 0 replies; 47+ messages in thread From: Rob Landley @ 2009-09-19 1:33 UTC (permalink / raw) To: kernel list From: Rob Landley <rob@xxxxxxxxxxx> 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 <rob@xxxxxxxxxxx> -- kernel/Makefile | 4 kernel/timeconst.pl | 378 ------------------------------------------ kernel/timeconst.sh | 91 ++++++++++ 3 files changed, 93 insertions(+), 380 deletions(-) diff -ruN linux-2.6.30/kernel/Makefile linux-2.6.30.new/kernel/Makefile --- linux-2.6.30/kernel/Makefile 2009-06-09 22:05:27.000000000 -0500 +++ linux-2.6.30.new/kernel/Makefile 2009-06-22 14:29:16.000000000 -0500 @@ -127,7 +127,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) diff -ruN linux-2.6.30/kernel/timeconst.pl linux-2.6.30.new/kernel/timeconst.pl --- linux-2.6.30/kernel/timeconst.pl 2009-06-09 22:05:27.000000000 -0500 +++ linux-2.6.30.new/kernel/timeconst.pl 1969-12-31 18:00:00.000000000 -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 => [ - '0xa6aaaaab','0x2aaaaaa',26, - 125,3, - '0xc49ba5e4','0x1fbe76c8b4',37, - 3,125, - '0xa2c2aaab','0xaaaa',16, - 125000,3, - '0xc9539b89','0x7fffbce4217d',47, - 3,125000, - ], 32 => [ - '0xfa000000','0x6000000',27, - 125,4, - '0x83126e98','0xfdf3b645a',36, - 4,125, - '0xf4240000','0x0',17, - 31250,1, - '0x8637bd06','0x3fff79c842fa',46, - 1,31250, - ], 48 => [ - '0xa6aaaaab','0x6aaaaaa',27, - 125,6, - '0xc49ba5e4','0xfdf3b645a',36, - 6,125, - '0xa2c2aaab','0x15555',17, - 62500,3, - '0xc9539b89','0x3fffbce4217d',46, - 3,62500, - ], 64 => [ - '0xfa000000','0xe000000',28, - 125,8, - '0x83126e98','0x7ef9db22d',35, - 8,125, - '0xf4240000','0x0',18, - 15625,1, - '0x8637bd06','0x1fff79c842fa',45, - 1,15625, - ], 100 => [ - '0xa0000000','0x0',28, - 10,1, - '0xcccccccd','0x733333333',35, - 1,10, - '0x9c400000','0x0',18, - 10000,1, - '0xd1b71759','0x1fff2e48e8a7',45, - 1,10000, - ], 122 => [ - '0x8325c53f','0xfbcda3a',28, - 500,61, - '0xf9db22d1','0x7fbe76c8b',35, - 61,500, - '0x8012e2a0','0x3ef36',18, - 500000,61, - '0xffda4053','0x1ffffbce4217',45, - 61,500000, - ], 128 => [ - '0xfa000000','0x1e000000',29, - 125,16, - '0x83126e98','0x3f7ced916',34, - 16,125, - '0xf4240000','0x40000',19, - 15625,2, - '0x8637bd06','0xfffbce4217d',44, - 2,15625, - ], 200 => [ - '0xa0000000','0x0',29, - 5,1, - '0xcccccccd','0x333333333',34, - 1,5, - '0x9c400000','0x0',19, - 5000,1, - '0xd1b71759','0xfff2e48e8a7',44, - 1,5000, - ], 250 => [ - '0x80000000','0x0',29, - 4,1, - '0x80000000','0x180000000',33, - 1,4, - '0xfa000000','0x0',20, - 4000,1, - '0x83126e98','0x7ff7ced9168',43, - 1,4000, - ], 256 => [ - '0xfa000000','0x3e000000',30, - 125,32, - '0x83126e98','0x1fbe76c8b',33, - 32,125, - '0xf4240000','0xc0000',20, - 15625,4, - '0x8637bd06','0x7ffde7210be',43, - 4,15625, - ], 300 => [ - '0xd5555556','0x2aaaaaaa',30, - 10,3, - '0x9999999a','0x1cccccccc',33, - 3,10, - '0xd0555556','0xaaaaa',20, - 10000,3, - '0x9d495183','0x7ffcb923a29',43, - 3,10000, - ], 512 => [ - '0xfa000000','0x7e000000',31, - 125,64, - '0x83126e98','0xfdf3b645',32, - 64,125, - '0xf4240000','0x1c0000',21, - 15625,8, - '0x8637bd06','0x3ffef39085f',42, - 8,15625, - ], 1000 => [ - '0x80000000','0x0',31, - 1,1, - '0x80000000','0x0',31, - 1,1, - '0xfa000000','0x0',22, - 1000,1, - '0x83126e98','0x1ff7ced9168',41, - 1,1000, - ], 1024 => [ - '0xfa000000','0xfe000000',32, - 125,128, - '0x83126e98','0x7ef9db22',31, - 128,125, - '0xf4240000','0x3c0000',22, - 15625,16, - '0x8637bd06','0x1fff79c842f',41, - 16,15625, - ], 1200 => [ - '0xd5555556','0xd5555555',32, - 5,6, - '0x9999999a','0x66666666',31, - 6,5, - '0xd0555556','0x2aaaaa',22, - 2500,3, - '0x9d495183','0x1ffcb923a29',41, - 3,2500, - ] -); - -$has_bigint = eval 'use Math::BigInt qw(bgcd); 1;'; - -sub bint($) -{ - my($x) = @_; - return Math::BigInt->new($x); -} - -# -# Constants for division by reciprocal multiplication. -# (bits, numerator, denominator) -# -sub fmul($$$) -{ - my ($b,$n,$d) = @_; - - $n = bint($n); - $d = bint($d); - - return scalar (($n << $b)+$d-bint(1))/$d; -} - -sub fadj($$$) -{ - my($b,$n,$d) = @_; - - $n = bint($n); - $d = bint($d); - - $d = $d/bgcd($n, $d); - return scalar (($d-bint(1)) << $b)/$d; -} - -sub fmuls($$$) { - my($b,$n,$d) = @_; - my($s,$m); - my($thres) = bint(1) << ($b-1); - - $n = bint($n); - $d = bint($d); - - for ($s = 0; 1; $s++) { - $m = fmul($s,$n,$d); - return $s if ($m >= $thres); - } - return 0; -} - -# Generate a hex value if the result fits in 64 bits; -# otherwise skip. -sub bignum_hex($) { - my($x) = @_; - my $s = $x->as_hex(); - - return (length($s) > 18) ? undef : $s; -} - -# Provides mul, adj, and shr factors for a specific -# (bit, time, hz) combination -sub muladj($$$) { - my($b, $t, $hz) = @_; - my $s = fmuls($b, $t, $hz); - my $m = fmul($s, $t, $hz); - my $a = fadj($s, $t, $hz); - return (bignum_hex($m), bignum_hex($a), $s); -} - -# Provides numerator, denominator values -sub numden($$) { - my($n, $d) = @_; - my $g = bgcd($n, $d); - return ($n/$g, $d/$g); -} - -# All values for a specific (time, hz) combo -sub conversions($$) { - my ($t, $hz) = @_; - my @val = (); - - # HZ_TO_xx - push(@val, muladj(32, $t, $hz)); - push(@val, numden($t, $hz)); - - # xx_TO_HZ - push(@val, muladj(32, $hz, $t)); - push(@val, numden($hz, $t)); - - return @val; -} - -sub compute_values($) { - my($hz) = @_; - my @val = (); - my $s, $m, $a, $g; - - if (!$has_bigint) { - die "$0: HZ == $hz not canned and ". - "Math::BigInt not available\n"; - } - - # MSEC conversions - push(@val, conversions(1000, $hz)); - - # USEC conversions - push(@val, conversions(1000000, $hz)); - - return @val; -} - -sub outputval($$) -{ - my($name, $val) = @_; - my $csuf; - - if (defined($val)) { - if ($name !~ /SHR/) { - $val = "U64_C($val)"; - } - printf "#define %-23s %s\n", $name.$csuf, $val.$csuf; - } -} - -sub output($@) -{ - my($hz, @val) = @_; - my $pfx, $bit, $suf, $s, $m, $a; - - print "/* Automatically generated by kernel/timeconst.pl */\n"; - print "/* Conversion constants for HZ == $hz */\n"; - print "\n"; - print "#ifndef KERNEL_TIMECONST_H\n"; - print "#define KERNEL_TIMECONST_H\n"; - print "\n"; - - print "#include <linux/param.h>\n"; - print "#include <linux/types.h>\n"; - - print "\n"; - print "#if HZ != $hz\n"; - print "#error \"kernel/timeconst.h has the wrong HZ value!\"\n"; - print "#endif\n"; - print "\n"; - - foreach $pfx ('HZ_TO_MSEC','MSEC_TO_HZ', - 'HZ_TO_USEC','USEC_TO_HZ') { - foreach $bit (32) { - foreach $suf ('MUL', 'ADJ', 'SHR') { - outputval("${pfx}_$suf$bit", shift(@val)); - } - } - foreach $suf ('NUM', 'DEN') { - outputval("${pfx}_$suf", shift(@val)); - } - } - - print "\n"; - print "#endif /* KERNEL_TIMECONST_H */\n"; -} - -# Pretty-print Perl values -sub perlvals(@) { - my $v; - my @l = (); - - foreach $v (@_) { - if (!defined($v)) { - push(@l, 'undef'); - } elsif ($v =~ /^0x/) { - push(@l, "\'".$v."\'"); - } else { - push(@l, $v.''); - } - } - return join(',', @l); -} - -($hz) = @ARGV; - -# Use this to generate the %canned_values structure -if ($hz eq '--can') { - shift(@ARGV); - @hzlist = sort {$a <=> $b} (@ARGV); - - print "# Precomputed values for systems without Math::BigInt\n"; - print "# Generated by:\n"; - print "# timeconst.pl --can ", join(' ', @hzlist), "\n"; - print "\%canned_values = (\n"; - my $pf = "\t"; - foreach $hz (@hzlist) { - my @values = compute_values($hz); - print "$pf$hz => [\n"; - while (scalar(@values)) { - my $bit; - foreach $bit (32) { - my $m = shift(@values); - my $a = shift(@values); - my $s = shift(@values); - print "\t\t", perlvals($m,$a,$s), ",\n"; - } - my $n = shift(@values); - my $d = shift(@values); - print "\t\t", perlvals($n,$d), ",\n"; - } - print "\t]"; - $pf = ', '; - } - print "\n);\n"; -} else { - $hz += 0; # Force to number - if ($hz < 1) { - die "Usage: $0 HZ\n"; - } - - @val = @{$canned_values{$hz}}; - if (!defined(@val)) { - @val = compute_values($hz); - } - output($hz, @val); -} -exit 0; diff -ruN linux-2.6.30/kernel/timeconst.sh linux-2.6.30.new/kernel/timeconst.sh --- linux-2.6.30/kernel/timeconst.sh 1969-12-31 18:00:00.000000000 -0600 +++ linux-2.6.30.new/kernel/timeconst.sh 2009-06-22 14:29:16.000000000 -0500 @@ -0,0 +1,148 @@ +#!/bin/sh + +if [ $# -ne 2 ] +then + echo "Usage: timeconst.sh HZ FILENAME" + echo + echo "Generate a header file with constants for coverting between" + echo "decimal HZ timer ticks and milisecond or microsecond delays." + echo + exit 1 +fi + +HZ=$1 +shift +FILENAME=$1 + +# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit math. + +if [ $((1 << 32)) -lt 0 ] +then + echo "timeconst.sh needs a shell with 64 bit math, such as bash," + echo "busybox ash, or dash running on a 64 bit host." + exit 1 +fi + +# If this script exits for any reason before this trap is removed, +# delete the output file so a partial file won't confuse the build. + +trap "rm $FILENAME" EXIT + +# Output start of header file + +cat > $FILENAME << EOF || exit 1 +/* Automatically generated by kernel/timeconst.sh */ +/* Conversion constants for HZ == $HZ */ + +#ifndef __KERNEL_TIMECONST_H +#define __KERNEL_TIMECONST_H + +#include <linux/param.h> +#include <linux/types.h> + +#if HZ != $HZ +#error "kernel/timeconst.h has the wrong HZ value!" +#endif + +EOF + +# For both Milliseconds and Microseconds + +cat << EOF | +MSEC 1000 +USEC 1000000 +EOF +while read NAME PERIOD +do + # 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 + + # Calculate 32 significant bits of MUL32 data. + + SHIFT=0 + while true + do + # This can't overflow 64 bit math. Pathological case + # (TO=1, FROM=1000000) uses around 32+20=52 bits. + + MUL32=$(( ( ( $TO << $SHIFT ) + $FROM - 1 ) / $FROM )) + + # Keep increasing $SHIFT until we've got 32 bits. + + [ $MUL32 -gt $(( 1 << 31 )) ] && break + SHIFT=$(( $SHIFT + 1 )) + done + MUL32=$( printf %x $MUL32 ) + + # ADJ32 is just (((FROM/GCD)-1)<<SHIFT)/(FROM/GCD) but this + # can overflow 64 bit math (examples, HZ=24 or HZ=122). + # Pathological case could use 32+20+20=72 bits. (And this is + # the pathological case because a larger $HZ results in a + # smaller $SHIFT, so even insane HZ>USEC cases should be ok.) + + # To get around this, we chop the bottom 32 bits off the + # calculation and then reassemble it to avoid overflow: + # 32+64=96, which is > 72. + + ADJ32=$(( $FROM / $GCD )) + if [ $SHIFT -gt 32 ] + then + UPPER=$(( ( $ADJ32 - 1 ) << ( $SHIFT - 32 ) )) + LOWER=$(( ( $UPPER % $ADJ32 ) << 32 )) + ADJ32=$(( ( ( $UPPER / $ADJ32 ) << 32 ) + ( $LOWER / $ADJ32 ))) + else + ADJ32=$(( ( ( $ADJ32 - 1 ) << $SHIFT) / $ADJ32 )) + fi + ADJ32=$( printf %x $ADJ32 ) + + NUM=$(( $TO / $GCD )) + DEN=$(( $FROM / $GCD )) + + # Output next chunk of header data to file + + ( + echo "#define ${CONVERT}_MUL32 U64_C(0x$MUL32)" && + echo "#define ${CONVERT}_ADJ32 U64_C(0x$ADJ32)" && + echo "#define ${CONVERT}_SHR32 $SHIFT" && + echo "#define ${CONVERT}_NUM U64_C($NUM)" && + echo "#define ${CONVERT}_DEN U64_C($DEN)" + ) >> $FILENAME || exit 1 + done +done + +( + echo + echo "#endif /* __KERNEL_TIMECHONST_H */" +) >> $FILENAME || exit 1 + +# Don't rm $FILENAME on exit anymore. + +trap "" EXIT + +exit 0 -- Latency is more important than throughput. It's that simple. - Linus Torvalds ^ permalink raw reply [flat|nested] 47+ messages in thread
* PATCH [0/3]: Simplify the kernel build by removing perl. @ 2009-01-02 8:07 Rob Landley 2009-01-02 8:13 ` [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley 0 siblings, 1 reply; 47+ messages in thread From: Rob Landley @ 2009-01-02 8:07 UTC (permalink / raw) To: Embedded Linux mailing list Cc: linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-02 8:07 PATCH [0/3]: Simplify the kernel build by removing perl Rob Landley @ 2009-01-02 8:13 ` Rob Landley 2009-01-02 9:04 ` Sam Ravnborg ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Rob Landley @ 2009-01-02 8:13 UTC (permalink / raw) To: Embedded Linux mailing list Cc: linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg From: Rob Landley <rob@landley.net> Replace kernel/timeconst.pl with kernel/timeconst.sh. The new shell scriptis 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 neverrequired perl to build. Signed-off-by: Rob Landley <rob@landley.net>--- 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.000000000 -0600+++ hg/kernel/timeconst.sh 2009-01-01 23:53:17.000000000 -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 <linux/param.h>+#include <linux/types.h>++#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 1000000"+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}_NUM U64_C($(($TO/$GCD)))"+ echo "#define ${CONVERT}_DEN U64_C($(($FROM/$GCD)))"+ done+done++echo+echo "#endif /* KERNEL_TIMECHONST_H */"--- hg/kernel/timeconst.pl 2008-11-22 19:09:13.000000000 -0600+++ /dev/null 1969-12-31 00:00:00.000000000 -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 => [- '0xa6aaaaab','0x2aaaaaa',26,- 125,3,- '0xc49ba5e4','0x1fbe76c8b4',37,- 3,125,- '0xa2c2aaab','0xaaaa',16,- 125000,3,- '0xc9539b89','0x7fffbce4217d',47,- 3,125000,- ], 32 => [- '0xfa000000','0x6000000',27,- 125,4,- '0x83126e98','0xfdf3b645a',36,- 4,125,- '0xf4240000','0x0',17,- 31250,1,- '0x8637bd06','0x3fff79c842fa',46,- 1,31250,- ], 48 => [- '0xa6aaaaab','0x6aaaaaa',27,- 125,6,- '0xc49ba5e4','0xfdf3b645a',36,- 6,125,- '0xa2c2aaab','0x15555',17,- 62500,3,- '0xc9539b89','0x3fffbce4217d',46,- 3,62500,- ], 64 => [- '0xfa000000','0xe000000',28,- 125,8,- '0x83126e98','0x7ef9db22d',35,- 8,125,- '0xf4240000','0x0',18,- 15625,1,- '0x8637bd06','0x1fff79c842fa',45,- 1,15625,- ], 100 => [- '0xa0000000','0x0',28,- 10,1,- '0xcccccccd','0x733333333',35,- 1,10,- '0x9c400000','0x0',18,- 10000,1,- '0xd1b71759','0x1fff2e48e8a7',45,- 1,10000,- ], 122 => [- '0x8325c53f','0xfbcda3a',28,- 500,61,- '0xf9db22d1','0x7fbe76c8b',35,- 61,500,- '0x8012e2a0','0x3ef36',18,- 500000,61,- '0xffda4053','0x1ffffbce4217',45,- 61,500000,- ], 128 => [- '0xfa000000','0x1e000000',29,- 125,16,- '0x83126e98','0x3f7ced916',34,- 16,125,- '0xf4240000','0x40000',19,- 15625,2,- '0x8637bd06','0xfffbce4217d',44,- 2,15625,- ], 200 => [- '0xa0000000','0x0',29,- 5,1,- '0xcccccccd','0x333333333',34,- 1,5,- '0x9c400000','0x0',19,- 5000,1,- '0xd1b71759','0xfff2e48e8a7',44,- 1,5000,- ], 250 => [- '0x80000000','0x0',29,- 4,1,- '0x80000000','0x180000000',33,- 1,4,- '0xfa000000','0x0',20,- 4000,1,- '0x83126e98','0x7ff7ced9168',43,- 1,4000,- ], 256 => [- '0xfa000000','0x3e000000',30,- 125,32,- '0x83126e98','0x1fbe76c8b',33,- 32,125,- '0xf4240000','0xc0000',20,- 15625,4,- '0x8637bd06','0x7ffde7210be',43,- 4,15625,- ], 300 => [- '0xd5555556','0x2aaaaaaa',30,- 10,3,- '0x9999999a','0x1cccccccc',33,- 3,10,- '0xd0555556','0xaaaaa',20,- 10000,3,- '0x9d495183','0x7ffcb923a29',43,- 3,10000,- ], 512 => [- '0xfa000000','0x7e000000',31,- 125,64,- '0x83126e98','0xfdf3b645',32,- 64,125,- '0xf4240000','0x1c0000',21,- 15625,8,- '0x8637bd06','0x3ffef39085f',42,- 8,15625,- ], 1000 => [- '0x80000000','0x0',31,- 1,1,- '0x80000000','0x0',31,- 1,1,- '0xfa000000','0x0',22,- 1000,1,- '0x83126e98','0x1ff7ced9168',41,- 1,1000,- ], 1024 => [- '0xfa000000','0xfe000000',32,- 125,128,- '0x83126e98','0x7ef9db22',31,- 128,125,- '0xf4240000','0x3c0000',22,- 15625,16,- '0x8637bd06','0x1fff79c842f',41,- 16,15625,- ], 1200 => [- '0xd5555556','0xd5555555',32,- 5,6,- '0x9999999a','0x66666666',31,- 6,5,- '0xd0555556','0x2aaaaa',22,- 2500,3,- '0x9d495183','0x1ffcb923a29',41,- 3,2500,- ]-);--$has_bigint = eval 'use Math::BigInt qw(bgcd); 1;';--sub bint($)-{- my($x) = @_;- return Math::BigInt->new($x);-}--#-# Constants for division by reciprocal multiplication.-# (bits, numerator, denominator)-#-sub fmul($$$)-{- my ($b,$n,$d) = @_;-- $n = bint($n);- $d = bint($d);-- return scalar (($n << $b)+$d-bint(1))/$d;-}--sub fadj($$$)-{- my($b,$n,$d) = @_;-- $n = bint($n);- $d = bint($d);-- $d = $d/bgcd($n, $d);- return scalar (($d-bint(1)) << $b)/$d;-}--sub fmuls($$$) {- my($b,$n,$d) = @_;- my($s,$m);- my($thres) = bint(1) << ($b-1);-- $n = bint($n);- $d = bint($d);-- for ($s = 0; 1; $s++) {- $m = fmul($s,$n,$d);- return $s if ($m >= $thres);- }- return 0;-}--# Generate a hex value if the result fits in 64 bits;-# otherwise skip.-sub bignum_hex($) {- my($x) = @_;- my $s = $x->as_hex();-- return (length($s) > 18) ? undef : $s;-}--# Provides mul, adj, and shr factors for a specific-# (bit, time, hz) combination-sub muladj($$$) {- my($b, $t, $hz) = @_;- my $s = fmuls($b, $t, $hz);- my $m = fmul($s, $t, $hz);- my $a = fadj($s, $t, $hz);- return (bignum_hex($m), bignum_hex($a), $s);-}--# Provides numerator, denominator values-sub numden($$) {- my($n, $d) = @_;- my $g = bgcd($n, $d);- return ($n/$g, $d/$g);-}--# All values for a specific (time, hz) combo-sub conversions($$) {- my ($t, $hz) = @_;- my @val = ();-- # HZ_TO_xx- push(@val, muladj(32, $t, $hz));- push(@val, numden($t, $hz));-- # xx_TO_HZ- push(@val, muladj(32, $hz, $t));- push(@val, numden($hz, $t));-- return @val;-}--sub compute_values($) {- my($hz) = @_;- my @val = ();- my $s, $m, $a, $g;-- if (!$has_bigint) {- die "$0: HZ == $hz not canned and ".- "Math::BigInt not available\n";- }-- # MSEC conversions- push(@val, conversions(1000, $hz));-- # USEC conversions- push(@val, conversions(1000000, $hz));-- return @val;-}--sub outputval($$)-{- my($name, $val) = @_;- my $csuf;-- if (defined($val)) {- if ($name !~ /SHR/) {- $val = "U64_C($val)";- }- printf "#define %-23s %s\n", $name.$csuf, $val.$csuf;- }-}--sub output($@)-{- my($hz, @val) = @_;- my $pfx, $bit, $suf, $s, $m, $a;-- print "/* Automatically generated by kernel/timeconst.pl */\n";- print "/* Conversion constants for HZ == $hz */\n";- print "\n";- print "#ifndef KERNEL_TIMECONST_H\n";- print "#define KERNEL_TIMECONST_H\n";- print "\n";-- print "#include <linux/param.h>\n";- print "#include <linux/types.h>\n";-- print "\n";- print "#if HZ != $hz\n";- print "#error \"kernel/timeconst.h has the wrong HZ value!\"\n";- print "#endif\n";- print "\n";-- foreach $pfx ('HZ_TO_MSEC','MSEC_TO_HZ',- 'HZ_TO_USEC','USEC_TO_HZ') {- foreach $bit (32) {- foreach $suf ('MUL', 'ADJ', 'SHR') {- outputval("${pfx}_$suf$bit", shift(@val));- }- }- foreach $suf ('NUM', 'DEN') {- outputval("${pfx}_$suf", shift(@val));- }- }-- print "\n";- print "#endif /* KERNEL_TIMECONST_H */\n";-}--# Pretty-print Perl values-sub perlvals(@) {- my $v;- my @l = ();-- foreach $v (@_) {- if (!defined($v)) {- push(@l, 'undef');- } elsif ($v =~ /^0x/) {- push(@l, "\'".$v."\'");- } else {- push(@l, $v.'');- }- }- return join(',', @l);-}--($hz) = @ARGV;--# Use this to generate the %canned_values structure-if ($hz eq '--can') {- shift(@ARGV);- @hzlist = sort {$a <=> $b} (@ARGV);-- print "# Precomputed values for systems without Math::BigInt\n";- print "# Generated by:\n";- print "# timeconst.pl --can ", join(' ', @hzlist), "\n";- print "\%canned_values = (\n";- my $pf = "\t";- foreach $hz (@hzlist) {- my @values = compute_values($hz);- print "$pf$hz => [\n";- while (scalar(@values)) {- my $bit;- foreach $bit (32) {- my $m = shift(@values);- my $a = shift(@values);- my $s = shift(@values);- print "\t\t", perlvals($m,$a,$s), ",\n";- }- my $n = shift(@values);- my $d = shift(@values);- print "\t\t", perlvals($n,$d), ",\n";- }- print "\t]";- $pf = ', ';- }- print "\n);\n";-} else {- $hz += 0; # Force to number- if ($hz < 1) {- die "Usage: $0 HZ\n";- }-- @val = @{$canned_values{$hz}};- if (!defined(@val)) {- @val = compute_values($hz);- }- output($hz, @val);-}-exit 0;\0ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-02 8:13 ` [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley @ 2009-01-02 9:04 ` Sam Ravnborg 2009-01-02 12:00 ` Rob Landley 2009-01-03 12:28 ` Ingo Oeser 2009-01-05 0:41 ` Ray Lee 2 siblings, 1 reply; 47+ messages in thread From: Sam Ravnborg @ 2009-01-02 9:04 UTC (permalink / raw) To: Rob Landley Cc: Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin Hi Rob. On Fri, Jan 02, 2009 at 02:13:30AM -0600, Rob Landley wrote: > From: Rob Landley <rob@landley.net> > > 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 <rob@landley.net> > --- > > 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.000000000 -0600 > +++ hg/kernel/timeconst.sh 2009-01-01 23:53:17.000000000 -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 <linux/param.h> > +#include <linux/types.h> > + > +#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 1000000" > +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}_NUM U64_C($(($TO/$GCD)))" > + echo "#define ${CONVERT}_DEN U64_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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-02 9:04 ` Sam Ravnborg @ 2009-01-02 12:00 ` Rob Landley 2009-01-02 19:33 ` H. Peter Anvin 2009-01-03 6:28 ` Harvey Harrison 0 siblings, 2 replies; 47+ messages in thread From: Rob Landley @ 2009-01-02 12:00 UTC (permalink / raw) To: Sam Ravnborg Cc: Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin 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 <rob@landley.net> > > > > 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 <rob@landley.net> > > --- > > > > 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.000000000 -0600 > > +++ hg/kernel/timeconst.sh 2009-01-01 23:53:17.000000000 -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 <linux/param.h> > > +#include <linux/types.h> > > + > > +#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 1000000" > > +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}_NUM U64_C($(($TO/$GCD)))" > > + echo "#define ${CONVERT}_DEN U64_C($(($FROM/$GCD)))" > > + done > > +done > > Is it a shell limitation that all spaces around operators are missing? > Makes it hard to read.. No, I was just trying to make sure I didn't go over the 80 char limit. (Several temporary variables are there primarily because the style guide says indentation should be via 8 space tabs.) I'll add some more spaces on the respin. > > 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. Well, preserve in this case. :) I can add an "EXIT" trap and then disarm it later, but the output is redirected in the makefile, so generating an error won't remove the output if you run again. Perhaps the file to create should be fed in as a second argument to the script, so the trap can "rm" the output file if it triggers? I'll poke at it in the morning. Thanks for the feedback, Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-02 12:00 ` Rob Landley @ 2009-01-02 19:33 ` H. Peter Anvin 2009-01-04 1:32 ` Rob Landley 2009-01-03 6:28 ` Harvey Harrison 1 sibling, 1 reply; 47+ messages in thread From: H. Peter Anvin @ 2009-01-02 19:33 UTC (permalink / raw) To: Rob Landley Cc: Sam Ravnborg, Embedded Linux mailing list, linux-kernel, Andrew Morton 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-02 19:33 ` H. Peter Anvin @ 2009-01-04 1:32 ` Rob Landley 2009-01-04 1:35 ` H. Peter Anvin 2009-01-04 12:07 ` Alan Cox 0 siblings, 2 replies; 47+ messages in thread From: Rob Landley @ 2009-01-04 1:32 UTC (permalink / raw) To: H. Peter Anvin Cc: Sam Ravnborg, Embedded Linux mailing list, linux-kernel, Andrew Morton On Friday 02 January 2009 13:33:02 H. Peter Anvin wrote: > 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. I note that sed and printf and such are all susv3. I have an explicit test for 32 bit math in the script that cares, and this worked in Red Hat 9 circa 2003. I consider this a step up from code with an implicit dependency on a CPAN library. > 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. A) I'm not using bc. B) You don't need arbitrary precision arithmetic, you need around 72 bits worth of arithmetic for the pathological case. C) Your definition of "access to arbitrary-precision arithmetic" includes the following, cut and paste verbatim from your old script: # 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 => [ '0xa6aaaaab','0x2aaaaaa',26, 125,3, '0xc49ba5e4','0x1fbe76c8b4',37, 3,125, '0xa2c2aaab','0xaaaa',16, 125000,3, '0xc9539b89','0x7fffbce4217d',47, 3,125000, ], 32 => [ '0xfa000000','0x6000000',27, 125,4, '0x83126e98','0xfdf3b645a',36, 4,125, '0xf4240000','0x0',17, 31250,1, '0x8637bd06','0x3fff79c842fa',46, 1,31250, ], 48 => [ '0xa6aaaaab','0x6aaaaaa',27, 125,6, '0xc49ba5e4','0xfdf3b645a',36, 6,125, '0xa2c2aaab','0x15555',17, 62500,3, '0xc9539b89','0x3fffbce4217d',46, 3,62500, ], 64 => [ '0xfa000000','0xe000000',28, 125,8, '0x83126e98','0x7ef9db22d',35, 8,125, '0xf4240000','0x0',18, 15625,1, '0x8637bd06','0x1fff79c842fa',45, 1,15625, ], 100 => [ '0xa0000000','0x0',28, 10,1, '0xcccccccd','0x733333333',35, 1,10, '0x9c400000','0x0',18, 10000,1, '0xd1b71759','0x1fff2e48e8a7',45, 1,10000, ], 122 => [ '0x8325c53f','0xfbcda3a',28, 500,61, '0xf9db22d1','0x7fbe76c8b',35, 61,500, '0x8012e2a0','0x3ef36',18, 500000,61, '0xffda4053','0x1ffffbce4217',45, 61,500000, ], 128 => [ '0xfa000000','0x1e000000',29, 125,16, '0x83126e98','0x3f7ced916',34, 16,125, '0xf4240000','0x40000',19, 15625,2, '0x8637bd06','0xfffbce4217d',44, 2,15625, ], 200 => [ '0xa0000000','0x0',29, 5,1, '0xcccccccd','0x333333333',34, 1,5, '0x9c400000','0x0',19, 5000,1, '0xd1b71759','0xfff2e48e8a7',44, 1,5000, ], 250 => [ '0x80000000','0x0',29, 4,1, '0x80000000','0x180000000',33, 1,4, '0xfa000000','0x0',20, 4000,1, '0x83126e98','0x7ff7ced9168',43, 1,4000, ], 256 => [ '0xfa000000','0x3e000000',30, 125,32, '0x83126e98','0x1fbe76c8b',33, 32,125, '0xf4240000','0xc0000',20, 15625,4, '0x8637bd06','0x7ffde7210be',43, 4,15625, ], 300 => [ '0xd5555556','0x2aaaaaaa',30, 10,3, '0x9999999a','0x1cccccccc',33, 3,10, '0xd0555556','0xaaaaa',20, 10000,3, '0x9d495183','0x7ffcb923a29',43, 3,10000, ], 512 => [ '0xfa000000','0x7e000000',31, 125,64, '0x83126e98','0xfdf3b645',32, 64,125, '0xf4240000','0x1c0000',21, 15625,8, '0x8637bd06','0x3ffef39085f',42, 8,15625, ], 1000 => [ '0x80000000','0x0',31, 1,1, '0x80000000','0x0',31, 1,1, '0xfa000000','0x0',22, 1000,1, '0x83126e98','0x1ff7ced9168',41, 1,1000, ], 1024 => [ '0xfa000000','0xfe000000',32, 125,128, '0x83126e98','0x7ef9db22',31, 128,125, '0xf4240000','0x3c0000',22, 15625,16, '0x8637bd06','0x1fff79c842f',41, 16,15625, ], 1200 => [ '0xd5555556','0xd5555555',32, 5,6, '0x9999999a','0x66666666',31, 6,5, '0xd0555556','0x2aaaaa',22, 2500,3, '0x9d495183','0x1ffcb923a29',41, 3,2500, ] ); Plus a decent chunk of the remaining logic was code to regenerate that table, and to figure out when to use the table and when to compute new values. (And erroring out if the system wasn't capable of doing so.) I don't understand why you didn't just precompute the actual header file output instead or precomputing perl source, but that's a side issue. Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 1:32 ` Rob Landley @ 2009-01-04 1:35 ` H. Peter Anvin 2009-01-04 12:07 ` Alan Cox 1 sibling, 0 replies; 47+ messages in thread From: H. Peter Anvin @ 2009-01-04 1:35 UTC (permalink / raw) To: Rob Landley Cc: Sam Ravnborg, Embedded Linux mailing list, linux-kernel, Andrew Morton Rob Landley wrote: > > I consider this a step up from code with an implicit dependency on a CPAN > library. > There is no CPAN library in use. Math::BigInt is a standard part of Perl, and the canned values is there only to support extremely old versions of Perl, or weird system configurations, as a belt-and-suspenders measure. -hpa ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 1:32 ` Rob Landley 2009-01-04 1:35 ` H. Peter Anvin @ 2009-01-04 12:07 ` Alan Cox 2009-01-04 18:36 ` H. Peter Anvin 2009-01-04 19:03 ` Rob Landley 1 sibling, 2 replies; 47+ messages in thread From: Alan Cox @ 2009-01-04 12:07 UTC (permalink / raw) To: Rob Landley Cc: H. Peter Anvin, Sam Ravnborg, Embedded Linux mailing list, linux-kernel, Andrew Morton > I note that sed and printf and such are all susv3. I have an explicit test > for 32 bit math in the script that cares, and this worked in Red Hat 9 circa > 2003. If you are trying to do arbitary precision maths using standard posix tools just use dc. That way the standard is explicit about what you will get. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 12:07 ` Alan Cox @ 2009-01-04 18:36 ` H. Peter Anvin 2009-01-04 19:03 ` Rob Landley 1 sibling, 0 replies; 47+ messages in thread From: H. Peter Anvin @ 2009-01-04 18:36 UTC (permalink / raw) To: Alan Cox Cc: Rob Landley, Sam Ravnborg, Embedded Linux mailing list, linux-kernel, Andrew Morton Alan Cox wrote: >> I note that sed and printf and such are all susv3. I have an explicit test >> for 32 bit math in the script that cares, and this worked in Red Hat 9 circa >> 2003. > > If you are trying to do arbitary precision maths using standard posix > tools just use dc. That way the standard is explicit about what you will > get. The original patch used bc. Unfortunately, it ran into bc bugs -- on some platforms like some of akpm's older test machines it would just hang. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 12:07 ` Alan Cox 2009-01-04 18:36 ` H. Peter Anvin @ 2009-01-04 19:03 ` Rob Landley 2009-01-04 20:39 ` H. Peter Anvin 1 sibling, 1 reply; 47+ messages in thread From: Rob Landley @ 2009-01-04 19:03 UTC (permalink / raw) To: Alan Cox Cc: H. Peter Anvin, Sam Ravnborg, Embedded Linux mailing list, linux-kernel, Andrew Morton On Sunday 04 January 2009 06:07:35 Alan Cox wrote: > > I note that sed and printf and such are all susv3. I have an explicit > > test for 32 bit math in the script that cares, and this worked in Red Hat > > 9 circa 2003. > > If you are trying to do arbitary precision maths using standard posix > tools just use dc. That way the standard is explicit about what you will > get. I looked at that, but: A) the Open Group Base Specifications (which I normally go by, since they're roughly synonymous with SUSv3 and Posix and available free on the web; they just released version 7 a week or so back) don't list dc as one of their utilities. (They mention bc, but not dc.) B) The busybox implementation of dc is crap. I got 'em to fix the bug where the output defaulted to binary instead of decimal, but the math is all done as floating point rather than arbitrary precision, and they don't implement the << operator. C) The only calculation which can overflow 64 bits (the ADJ32 one) turns out not to need arbitrary precision math, just 72 bits, and if it ever uses more than 32 then bottom 32 are all zero before the divide so you can do it in three lines. Essentially, the ADJ32 calculation is "(($NUMBER-1)<<$SHIFT)/$NUMBER". $SHIFT maxes out at 51 and the largest interesting $NUMBER is 1000000. (That's the pathological case of HZ=1, calculating the USEC_TO_HZ direction. A larger $HZ results in a smaller $SHIFT by the number of bits needed to store $HZ, by the way, so a $HZ of 17 would have a shift of 47. So even a HZ bigger than a million should have a small enough $SHIFT not to cause trouble here, although that's probably an _insane_ input to this script.) 1 million needs 20 bits to store, so the above calculation has to cope with an intermediate value of 999999<<51 which takes a little over 70 bits to store, hence the potential to overflow 63 bits of signed math. But this calculation has two special properties: 1) The number you start with before the shift is divided back out at the end (more or less), so the _result_ has to be less than 1<<$SHIFT and thus only takes $SHIFT bits to store. With a maximum $SHIFT of 51 it has to fit in a 64 bit result with about a dozen bits to spare. 2) The bottom $SHIFT many bits are all zero before the divide. We can use these two properties to easily break the math into chunks that can't overflow by: a) Chopping off the bottom X bits and dividing what's left by $NUMBER, keeping both the dividend and the remainder. Choose any X that's big enough that this step won't overflow. (I chose X=32, leaving at most 40-ish bits here). b) Shift that dividend X bits to the left. This can't overflow because of special property 1 above. c) Shift the remainder X bits to the left. The remainder can't be larger than the $NUMBER you started with, so if X+bits($NUMBER)<64 this has to fit too. With X=32 and bits=20 we again have a dozen bits to spare. d) Add the results of (b) and (c) together. Since the bottom X bits were all zero, this is equivalent to having done the full divide. (Easy enough to mask those bottom bits off and add them to the remainder before the divide if they weren't, but we didn't need to do that because we know they were zero.) So no arbitrary precision math is actually required here, and yes there's a comment in the source about this. :) Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 19:03 ` Rob Landley @ 2009-01-04 20:39 ` H. Peter Anvin 2009-01-05 0:59 ` Rob Landley 0 siblings, 1 reply; 47+ messages in thread From: H. Peter Anvin @ 2009-01-04 20:39 UTC (permalink / raw) To: Rob Landley Cc: Alan Cox, Sam Ravnborg, Embedded Linux mailing list, linux-kernel, Andrew Morton Rob Landley wrote: > > C) The only calculation which can overflow 64 bits (the ADJ32 one) turns out > not to need arbitrary precision math, just 72 bits, and if it ever uses more > than 32 then bottom 32 are all zero before the divide so you can do it in > three lines. > ... for the current code (32 bits). When we get an overflow-less 64-bit implementation, this code will have to be redone, which is not true for a properly done implementation. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 20:39 ` H. Peter Anvin @ 2009-01-05 0:59 ` Rob Landley 0 siblings, 0 replies; 47+ messages in thread From: Rob Landley @ 2009-01-05 0:59 UTC (permalink / raw) To: H. Peter Anvin Cc: Alan Cox, Sam Ravnborg, Embedded Linux mailing list, linux-kernel, Andrew Morton On Sunday 04 January 2009 14:39:36 H. Peter Anvin wrote: > Rob Landley wrote: > > C) The only calculation which can overflow 64 bits (the ADJ32 one) turns > > out not to need arbitrary precision math, just 72 bits, and if it ever > > uses more than 32 then bottom 32 are all zero before the divide so you > > can do it in three lines. > > ... for the current code (32 bits). When we get an overflow-less 64-bit > implementation, this code will have to be redone, which is not true for > a properly done implementation. One extra mask and add is a strange definition of "redone", but I can add it now if you like. (I'd personally prefer to wait for something to actually need it, but...) > -hpa Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-02 12:00 ` Rob Landley 2009-01-02 19:33 ` H. Peter Anvin @ 2009-01-03 6:28 ` Harvey Harrison 1 sibling, 0 replies; 47+ messages in thread From: Harvey Harrison @ 2009-01-03 6:28 UTC (permalink / raw) To: Rob Landley Cc: Sam Ravnborg, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-02 8:13 ` [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley 2009-01-02 9:04 ` Sam Ravnborg @ 2009-01-03 12:28 ` Ingo Oeser 2009-01-04 1:36 ` Rob Landley 2009-01-05 0:41 ` Ray Lee 2 siblings, 1 reply; 47+ messages in thread From: Ingo Oeser @ 2009-01-03 12:28 UTC (permalink / raw) To: Rob Landley Cc: Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg Hi Robert, I fully support your argument here: Requiring lots of hacks in various languages to build a system core sucks. But now sth. more productive: On Friday 02 January 2009, Rob Landley wrote: > 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.000000000 -0600 > +++ hg/kernel/timeconst.sh 2009-01-01 23:53:17.000000000 -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 <linux/param.h> > +#include <linux/types.h> > + > +#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 1000000" > +do > + NAME=$(echo $i | awk '{print $1}') cut -d' ' -f1 does the same > + PERIOD=$(echo $i | awk '{print $2}') cut -d' ' -f2 does the same Best Regards Ingo Oeser ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-03 12:28 ` Ingo Oeser @ 2009-01-04 1:36 ` Rob Landley 2009-01-04 5:07 ` Valdis.Kletnieks 2009-01-04 7:15 ` Michal Jaegermann 0 siblings, 2 replies; 47+ messages in thread From: Rob Landley @ 2009-01-04 1:36 UTC (permalink / raw) To: Ingo Oeser Cc: Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote: > > +for i in "MSEC 1000" "USEC 1000000" > > +do > > + NAME=$(echo $i | awk '{print $1}') > > cut -d' ' -f1 does the same > > > + PERIOD=$(echo $i | awk '{print $2}') > > cut -d' ' -f2 does the same >From a standards perspective http://www.opengroup.org/onlinepubs/9699919799/utilities/cut.html vs http://www.opengroup.org/onlinepubs/9699919799/utilities/awk.html is probably a wash, but from a simplicity perspective using the tool that _isn't_ its own programming language is probably a win. :) I made the change in the second round of patches I just posted. Thanks, Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 1:36 ` Rob Landley @ 2009-01-04 5:07 ` Valdis.Kletnieks 2009-01-04 6:43 ` Rob Landley 2009-01-04 21:51 ` Alejandro Mery 2009-01-04 7:15 ` Michal Jaegermann 1 sibling, 2 replies; 47+ messages in thread From: Valdis.Kletnieks @ 2009-01-04 5:07 UTC (permalink / raw) To: Rob Landley Cc: Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg [-- Attachment #1: Type: text/plain, Size: 769 bytes --] On Sat, 03 Jan 2009 19:36:04 CST, Rob Landley said: > On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote: > > > +for i in "MSEC 1000" "USEC 1000000" > > > +do > > > + NAME=$(echo $i | awk '{print $1}') > > > > cut -d' ' -f1 does the same > > > > > + PERIOD=$(echo $i | awk '{print $2}') > > > > cut -d' ' -f2 does the same Close, but no cee-gar. cut does something counter-intuitive with multiple blanks: % echo 'a b' | awk '{print $2}' b % echo 'a b' | cut -d' ' -f2 % echo 'a b' | sed -r 's/[ ]+/ /g' | cut -d' ' -f2 b Unfortunately, 'sed -r' isn't in the opengroup.org list of required options, and sed 's/ / /g' doesn't DTRT for 3 or more blanks (as it won't recursively apply the change to a *new* double blank formed by the previous change). [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 5:07 ` Valdis.Kletnieks @ 2009-01-04 6:43 ` Rob Landley 2009-01-04 22:13 ` Jamie Lokier 2009-01-04 21:51 ` Alejandro Mery 1 sibling, 1 reply; 47+ messages in thread From: Rob Landley @ 2009-01-04 6:43 UTC (permalink / raw) To: Valdis.Kletnieks Cc: Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Saturday 03 January 2009 23:07:55 Valdis.Kletnieks@vt.edu wrote: > On Sat, 03 Jan 2009 19:36:04 CST, Rob Landley said: > > On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote: > > > > +for i in "MSEC 1000" "USEC 1000000" > > > > +do > > > > + NAME=$(echo $i | awk '{print $1}') > > > > > > cut -d' ' -f1 does the same > > > > > > > + PERIOD=$(echo $i | awk '{print $2}') > > > > > > cut -d' ' -f2 does the same > > Close, but no cee-gar. cut does something counter-intuitive with multiple > blanks: Yes, but in this case I'm the one passing in the data so I know there aren't multiple blanks. (Or tabs instead of spaces.) In a private email, Bernd Petrovitsch suggested "set -- $i" and then using NAME=$1; PERIOD=$2. (I keep getting private email responses to these sort of threads, and then getting dismissed as the only one who cares about the issue. Less so this time around, but still...) This apparently works all the way back to the bourne shell. Not worth rolling another patch for, but if I do wind up rolling another patch for other reasons I might switch over to that. Both "cut" and "awk" are susv3, though. Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 6:43 ` Rob Landley @ 2009-01-04 22:13 ` Jamie Lokier 2009-01-05 0:15 ` Bernd Petrovitsch 0 siblings, 1 reply; 47+ messages in thread From: Jamie Lokier @ 2009-01-04 22:13 UTC (permalink / raw) To: Rob Landley Cc: Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg Rob Landley wrote: > In a private email, Bernd Petrovitsch suggested "set -- $i" and then > using NAME=$1; PERIOD=$2. (I keep getting private email responses > to these sort of threads, and then getting dismissed as the only one > who cares about the issue. Less so this time around, but still...) > This apparently works all the way back to the bourne shell. If you're going "all the way back to the bourne shell", don't use "set -- $i"; use "set x $i" instead, and don't expect to do any arithmetic in the shell; use "expr" or "awk" for arithmetic. (Not relevant to kernel scripts, imho, since you can always assume something a bit more modern and not too stripped down). (I have 850 Linux boxes on my network with a bourne shell which doesn't do $((...)). I won't be building kernels on them though :-) -- Jamie ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 22:13 ` Jamie Lokier @ 2009-01-05 0:15 ` Bernd Petrovitsch 2009-01-05 2:23 ` Jamie Lokier 2009-01-05 4:50 ` Rob Landley 0 siblings, 2 replies; 47+ messages in thread From: Bernd Petrovitsch @ 2009-01-05 0:15 UTC (permalink / raw) To: Jamie Lokier Cc: Rob Landley, Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Son, 2009-01-04 at 22:13 +0000, Jamie Lokier wrote: > Rob Landley wrote: > > In a private email, Bernd Petrovitsch suggested "set -- $i" and then > > using NAME=$1; PERIOD=$2. (I keep getting private email responses > > to these sort of threads, and then getting dismissed as the only one > > who cares about the issue. Less so this time around, but still...) > > This apparently works all the way back to the bourne shell. > > If you're going "all the way back to the bourne shell", don't use "set "Going back to a Bourne shell" was neither the intention nor makes it sense IMHO. I mentioned it to point out that the `set -- ' (or `set x `) is nothing new or even a bash-ism. > -- $i"; use "set x $i" instead, and don't expect to do any arithmetic > in the shell; use "expr" or "awk" for arithmetic. > > (Not relevant to kernel scripts, imho, since you can always assume > something a bit more modern and not too stripped down). ACK. A bash can IMHO be expected. Even going for `dash` is IMHO somewhat too extreme. > (I have 850 Linux boxes on my network with a bourne shell which > doesn't do $((...)). I won't be building kernels on them though :-) Believe it or not, but there are folks out there who build the firmware on ARM 200 MHz NFS-mounted systems natively (and not simply cross-compile it on a 2GHz PC .....). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-05 0:15 ` Bernd Petrovitsch @ 2009-01-05 2:23 ` Jamie Lokier 2009-01-05 10:46 ` Bernd Petrovitsch 2009-01-05 4:50 ` Rob Landley 1 sibling, 1 reply; 47+ messages in thread From: Jamie Lokier @ 2009-01-05 2:23 UTC (permalink / raw) To: Bernd Petrovitsch Cc: Rob Landley, Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg Bernd Petrovitsch wrote: > > (I have 850 Linux boxes on my network with a bourne shell which > > doesn't do $((...)). I won't be building kernels on them though :-) > > Believe it or not, but there are folks out there who build the firmware > on ARM 200 MHz NFS-mounted systems natively (and not simply > cross-compile it on a 2GHz PC .....). Really? My 850 Linux boxes are 166MHz ARMs and occasionally NFS-mounted. Their /bin/sh does not do $((...)), and Bash is not there at all. If I were installing GCC natively on them, I'd install GNU Make and a proper shell while I were at it. But I don't know if Bash works properly without fork()* - or even if GCC does :-) Perl might be hard, as shared libraries aren't supported by the toolchain which targets my ARMs* and Perl likes its loadable modules. I'm not sure why I would want to build a kernel on these devices. But I see why people with mobile ARM devices like gphones might want to, when they're out travelling. -- Jamie (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add proper shared libs. Feel free to fund this :-) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-05 2:23 ` Jamie Lokier @ 2009-01-05 10:46 ` Bernd Petrovitsch 2009-01-05 15:01 ` Jamie Lokier 2009-01-05 21:07 ` Rob Landley 0 siblings, 2 replies; 47+ messages in thread From: Bernd Petrovitsch @ 2009-01-05 10:46 UTC (permalink / raw) To: Jamie Lokier Cc: Rob Landley, Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Mon, 2009-01-05 at 02:23 +0000, Jamie Lokier wrote: > Bernd Petrovitsch wrote: > > > (I have 850 Linux boxes on my network with a bourne shell which > > > doesn't do $((...)). I won't be building kernels on them though :-) > > > > Believe it or not, but there are folks out there who build the firmware > > on ARM 200 MHz NFS-mounted systems natively (and not simply > > cross-compile it on a 2GHz PC .....). > > Really? > > My 850 Linux boxes are 166MHz ARMs and occasionally NFS-mounted. > Their /bin/sh does not do $((...)), and Bash is not there at all. I assume that the NFS-mounted root filesystem is a real distribution. And on the local flash is a usual busybox based firmware. > If I were installing GCC natively on them, I'd install GNU Make and a > proper shell while I were at it. But I don't know if Bash works ACK. > properly without fork()* - or even if GCC does :-) > > Perl might be hard, as shared libraries aren't supported by the > toolchain which targets my ARMs* and Perl likes its loadable modules. The simplest way to go is probably to use CentOS or Debian or another ready binary distribution on ARM (or MIPS or PPC or whatever core the embedded system has) possibly on a custom build kernel (if necessary). [...] > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add > proper shared libs. Feel free to fund this :-) The above mentioned ARMs have a MMU. Without MMU, it would be truly insane IMHO. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-05 10:46 ` Bernd Petrovitsch @ 2009-01-05 15:01 ` Jamie Lokier 2009-01-05 16:18 ` Bernd Petrovitsch 2009-01-06 0:06 ` Rob Landley 2009-01-05 21:07 ` Rob Landley 1 sibling, 2 replies; 47+ messages in thread From: Jamie Lokier @ 2009-01-05 15:01 UTC (permalink / raw) To: Bernd Petrovitsch Cc: Rob Landley, Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg Bernd Petrovitsch wrote: > I assume that the NFS-mounted root filesystem is a real distribution. Not unless you call uClinux (MMU-less) a real distribution, no. > > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add > > proper shared libs. Feel free to fund this :-) > > The above mentioned ARMs have a MMU. Without MMU, it would be truly > insane IMHO. We have similar cross-build issues without MMUs... I.e. that a lot of useful packages don't cross-build properly (including many which use Autoconf), and it might be easier to make a native build environment than to debug and patch all the broken-for-cross-build packages. Especially as sometimes they build, but fail at run-time in some conditions. But you're right it's probably insane to try. I haven't dared as I suspect GCC and/or Binutils would break too :-) I'm sticking instead with "oh well cross-build a few packages by hand and just don't even _try_ to use most of the handy software out there". You mentioned ARM Debian. According to http://wiki.debian.org/ArmEabiPort one recommended method of bootstrapping it is building natively on an emulated ARM, because cross-building is fragile. -- Jamie ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-05 15:01 ` Jamie Lokier @ 2009-01-05 16:18 ` Bernd Petrovitsch 2009-01-06 0:06 ` Rob Landley 1 sibling, 0 replies; 47+ messages in thread From: Bernd Petrovitsch @ 2009-01-05 16:18 UTC (permalink / raw) To: Jamie Lokier Cc: Rob Landley, Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Mon, 2009-01-05 at 15:01 +0000, Jamie Lokier wrote: > Bernd Petrovitsch wrote: > > I assume that the NFS-mounted root filesystem is a real distribution. > > Not unless you call uClinux (MMU-less) a real distribution, no. Not really. > > > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add > > > proper shared libs. Feel free to fund this :-) > > > > The above mentioned ARMs have a MMU. Without MMU, it would be truly > > insane IMHO. > > We have similar cross-build issues without MMUs... I.e. that a lot of Of course. > useful packages don't cross-build properly (including many which use > Autoconf), and it might be easier to make a native build environment Tell me about it - AC_TRY_RUN() is the culprit. And `pkg-config` supports cross-compilation only since 18 months or so. Before one had to rewrite the generated .pc files. [...] > You mentioned ARM Debian. According to > http://wiki.debian.org/ArmEabiPort one recommended method of > bootstrapping it is building natively on an emulated ARM, because > cross-building is fragile. That's of course the other solution - if qemu supports your $EMBEDDED_CPU good enough. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-05 15:01 ` Jamie Lokier 2009-01-05 16:18 ` Bernd Petrovitsch @ 2009-01-06 0:06 ` Rob Landley 1 sibling, 0 replies; 47+ messages in thread From: Rob Landley @ 2009-01-06 0:06 UTC (permalink / raw) To: Jamie Lokier Cc: Bernd Petrovitsch, Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Monday 05 January 2009 09:01:56 Jamie Lokier wrote: > Bernd Petrovitsch wrote: > > I assume that the NFS-mounted root filesystem is a real distribution. > > Not unless you call uClinux (MMU-less) a real distribution, no. I want things to be orthogonal. The following should be completely separate steps: 1) Creating a cross compiler 2) building a native development environment 3) booting a native development environment (on real hardware or under and emulator) 4) natively building your target system. You should be able to mix and match. Crosstool for #1, go download "fedora for arm" instead of #2, qemu or real hardware is your choice for #3, and then you should be able to natively build gentoo under an ubuntu host or vice versa. (How is not currently properly documented, but I'm working on that.) My objection to build systems like buildroot or uClinux is that they bundle all this together into a big hairball. They create their own cross compiler, build their own root file system, use their own packaging system, and you have to take it all or nothing. My build system is ruthlessly orthogonal. I try not to make it depend on other bits of _itself_ more than necessary. > > > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add > > > proper shared libs. Feel free to fund this :-) > > > > The above mentioned ARMs have a MMU. Without MMU, it would be truly > > insane IMHO. > > We have similar cross-build issues without MMUs... I.e. that a lot of > useful packages don't cross-build properly (including many which use > Autoconf), and it might be easier to make a native build environment > than to debug and patch all the broken-for-cross-build packages. > Especially as sometimes they build, but fail at run-time in some > conditions. If you can get a version of the same architecture with an mmu you can actually build natively on that. It's not ideal (it's a bit like trying to build i486 code on an i686; the fact it runs on the host is no guarantee it'll run on the target), but it's better than cross compiling. And most things have a broad enough compatible "base architecture" that you can mostly get away with it. > But you're right it's probably insane to try. I haven't dared as I > suspect GCC and/or Binutils would break too :-) Oh it does, but you can fix it. :) > I'm sticking instead with "oh well cross-build a few packages by hand > and just don't even _try_ to use most of the handy software out there". Cross compiling doesn't scale, and it bit-rots insanely quickly. > You mentioned ARM Debian. According to > http://wiki.debian.org/ArmEabiPort one recommended method of > bootstrapping it is building natively on an emulated ARM, because > cross-building is fragile. That's what my firmware linux project does too. (I believe I was one of the first doing this back in 2006, but there are three or four others out there doing it now.) Native compiling under emulation is an idea whose time has come. Emulators on cheap x86-64 laptops today are about as powerful as high end tricked out build servers circa 2001, and Moore's Law continues to advance. More memory, more CPU (maybe via SMP but distcc can take advantage of that today and qemu will develop threading someday). You can throw engineering time at the problem (making cross compiling work) or you can throw hardware at the problem (build natively and buy fast native or emulator-hosting hardware). The balance used to be in favor of the former; not so much anymore. That said, my drive for reproducibility and orthogonality says that your native development environment must be something you can reproduce entirely from source on an arbitrary host. You can't make cross compiling go away entirely, the best you can do is limit it to bootstrapping the native environment. But I want to keep the parts I have to cross compile as small and simple as possible, and then run a native build script to get a richer environment. For the past 5+ years my definition has been "an environment that can rebuild itself under itself is powerful enough, that's all I need to cross compile", and from the first time I tried this (late 2002) up until 2.6.25 that was 7 packages. That's why I responded to the addition of perl as a regression, because for my use case it was. > -- Jamie Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-05 10:46 ` Bernd Petrovitsch 2009-01-05 15:01 ` Jamie Lokier @ 2009-01-05 21:07 ` Rob Landley 1 sibling, 0 replies; 47+ messages in thread From: Rob Landley @ 2009-01-05 21:07 UTC (permalink / raw) To: Bernd Petrovitsch Cc: Jamie Lokier, Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Monday 05 January 2009 04:46:18 Bernd Petrovitsch wrote: > > My 850 Linux boxes are 166MHz ARMs and occasionally NFS-mounted. > > Their /bin/sh does not do $((...)), and Bash is not there at all. > > I assume that the NFS-mounted root filesystem is a real distribution. > And on the local flash is a usual busybox based firmware. Building on an nfs mount is evil. Make cares greatly about timestamp accuracy, and NFS's dentry cacheing doesn't really, especially when it discards cached copies and re-fetches them, and the server and client's clocks are a half-second off from each other. Sometimes you haven't got a choice, but I hate having to debug the build problems this intermittently causes. If you never do anything except "make all" it should suck less. > > If I were installing GCC natively on them, I'd install GNU Make and a > > proper shell while I were at it. But I don't know if Bash works > > ACK. > > > properly without fork()* - or even if GCC does :-) > > > > Perl might be hard, as shared libraries aren't supported by the > > toolchain which targets my ARMs* and Perl likes its loadable modules. > > The simplest way to go is probably to use CentOS or Debian or another > ready binary distribution on ARM (or MIPS or PPC or whatever core the > embedded system has) possibly on a custom build kernel (if necessary). Building natively on target hardware or under QEMU is growing in popularity. That's how the non-x86 versions of major distros build, and they even have policy documents about it. Here's Fedora's: http://fedoraproject.org/wiki/Architectures/ARM#Native_Compilation And here are the guys who opened the door for Ubuntu's official Arm port: http://mojo.handhelds.org/files/HandheldsMojo_ELC2008.pdf Of course hobbyists like myself haven't got the budget to buy a cluster of high-end arm systems and they're not always even _available_ for things like cris, and for new architectures (Xylinx microblaze anyone?) you'll always have to cross compile to bootstrap the first development environment on 'em anyway, and it's nice for your environment to be _reproducible_... So a more flexible approach is to cross compile just enough to get a working native development environment on the target, and then continue the build natively (whether it's under qemu or on a sufficiently powerful piece of target hardware). That's what my "art piece" Firmware Linux project does, and there's a scratchbox rewrite (sbox2, http://www.freedesktop.org/wiki/Software/sbox2 ) that does the same sort of thing, and there are others out there in various states of development. With x86 hardware so cheap and powerful, building under emulation for less powerful targets starts to make sense. Building natively under emulation (QEMU) is available to hobbyists like me and avoids most of the fun cross compiling issues you don't find out about until after you've shipped the system and somebody tries to do something with it you didn't test. So far the record for diagnosing one of these is the two full- time weeks my friend Garrett spent back at TimeSys tracking down why perl signal handling wasn't working on mips; turned out it was using x86 signal numbers rather which don't match the mips ones. The BSP had been shipping for over a year at that point, but nobody had ever tried to do signal handling in perl on mips before, and since the perl ./configure step is written in perl finding the broken part took some doing. This was back in the mists of early 2007 so it's ancient history by now, of course... If you have set up a cross compiler, you can configure QEMU to use distcc to call out through its virtual network to the cross compiler running on the host, which gives you a speed boost without reintroducing most of the horrible cross compiling issues: there's still only a native toolchain so your build doesn't have to keep two contexts (hostcc/targetcc) straight, ./configure still runs natively so any binaries it builds can run and any questions it asks about the host it's building on should give the right answers for the target it's building for (including uname -m and friends), headers are #included natively and libraries are linked natively (that's just how distcc works, preprocessing and linking happen on the local machine) and there's only one set so they can't accidentally mix and the cross compiler isn't even _involved_ in that, make runs natively so it won't get confused by strange environment variables (yeah, seen that one)...) Only the heavy lifting of compiling preprocessed .c files to .o files gets exported, which is the one thing the cross compiler can't really screw up. But bootstraping a native build environment to run under the emulator is something you want to keep down to as few packages as possible, because if you're trying to get the same behavior across half a dozen boards, cross compiling breaks every time you upgrade _anything_. > [...] > > > (* - No MMU on some ARMs, but I'm working on ARM FDPIC-ELF to add > > proper shared libs. Feel free to fund this :-) > > The above mentioned ARMs have a MMU. Without MMU, it would be truly > insane IMHO. Without an mmu you have a restricted set of packages that run anyway. No variable length stacks, you have to use vfork() instead of fork() (no copy on write), memory fragmentation is a big problem so malloc() fails way more often... So toolchain problems aren't a "hump" to get past on nommu systems: the area past that it isn't necessarily any easier. > Bernd Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-05 0:15 ` Bernd Petrovitsch 2009-01-05 2:23 ` Jamie Lokier @ 2009-01-05 4:50 ` Rob Landley 2009-01-05 12:29 ` Bernd Petrovitsch 1 sibling, 1 reply; 47+ messages in thread From: Rob Landley @ 2009-01-05 4:50 UTC (permalink / raw) To: Bernd Petrovitsch Cc: Jamie Lokier, Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Sunday 04 January 2009 18:15:30 Bernd Petrovitsch wrote: > On Son, 2009-01-04 at 22:13 +0000, Jamie Lokier wrote: > > Rob Landley wrote: > > > In a private email, Bernd Petrovitsch suggested "set -- $i" and then > > > using NAME=$1; PERIOD=$2. (I keep getting private email responses > > > to these sort of threads, and then getting dismissed as the only one > > > who cares about the issue. Less so this time around, but still...) > > > This apparently works all the way back to the bourne shell. > > > > If you're going "all the way back to the bourne shell", don't use "set > > "Going back to a Bourne shell" was neither the intention nor makes it > sense IMHO. > I mentioned it to point out that the `set -- ' (or `set x `) is nothing > new or even a bash-ism. > > > -- $i"; use "set x $i" instead, and don't expect to do any arithmetic > > in the shell; use "expr" or "awk" for arithmetic. > > > > (Not relevant to kernel scripts, imho, since you can always assume > > something a bit more modern and not too stripped down). > > ACK. A bash can IMHO be expected. Even going for `dash` is IMHO somewhat > too extreme. I have yet to encounter a system that uses dash _without_ bash. (All ubuntu variants, even jeos, install bash by default. They moved the /bin/sh symlink but they didn't stop installing bash, and the kernel will preferentially use bash if it finds it.) People keep telling me they exist. I suppose you could uninstall bash. You could also uninstall gcc. Not sure what that proves. (And nobody's shown me this mythical second implementation of perl that all these perl scripts are supposed to be portable to...) Busybox ash is a more interesting case, but that implements lots of bash extensions. That said, it's easy enough the scripts to work with current versions of dash. The whole shell portability issue mostly seems to be a stand-in for other objections (Peter Anvin didn't change syslinux and klibc to require perl to build this year because of dash), but it's easy enough to just address the proxy objection and move on rather than arguing about it... > > (I have 850 Linux boxes on my network with a bourne shell which > > doesn't do $((...)). I won't be building kernels on them though :-) > > Believe it or not, but there are folks out there who build the firmware > on ARM 200 MHz NFS-mounted systems natively (and not simply > cross-compile it on a 2GHz PC .....). Yeah, but according to Changes if they do it with the current kernel they do it with at least gcc 3.2 (August 2002) and make 3.79.1 (June 2000), so trying to make it work on software released pre-Y2K probably isn't that high a priority. :) > Bernd Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-05 4:50 ` Rob Landley @ 2009-01-05 12:29 ` Bernd Petrovitsch 0 siblings, 0 replies; 47+ messages in thread From: Bernd Petrovitsch @ 2009-01-05 12:29 UTC (permalink / raw) To: Rob Landley Cc: Jamie Lokier, Valdis.Kletnieks, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Son, 2009-01-04 at 22:50 -0600, Rob Landley wrote: > On Sunday 04 January 2009 18:15:30 Bernd Petrovitsch wrote: [...] > > ACK. A bash can IMHO be expected. Even going for `dash` is IMHO somewhat > > too extreme. > > I have yet to encounter a system that uses dash _without_ bash. (All ubuntu Hmm, should be doable with a chroot environment quite cheap and simple. > variants, even jeos, install bash by default. They moved the /bin/sh symlink Yes, I know (small) embedded systems that have a bash (and not "only" one of busybox shells). It eases writing somewhat fast shell scripts without the need for lots of fork()s+exec()s too ..... Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 5:07 ` Valdis.Kletnieks 2009-01-04 6:43 ` Rob Landley @ 2009-01-04 21:51 ` Alejandro Mery 1 sibling, 0 replies; 47+ messages in thread From: Alejandro Mery @ 2009-01-04 21:51 UTC (permalink / raw) To: Valdis.Kletnieks Cc: Rob Landley, Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg [-- Attachment #1: Type: text/plain, Size: 579 bytes --] Valdis.Kletnieks@vt.edu wrote: > Close, but no cee-gar. cut does something counter-intuitive with multiple > blanks: > > % echo 'a b' | awk '{print $2}' > b > % echo 'a b' | cut -d' ' -f2 > > % echo 'a b' | sed -r 's/[ ]+/ /g' | cut -d' ' -f2 > b > > Unfortunately, 'sed -r' isn't in the opengroup.org list of required options, > and sed 's/ / /g' doesn't DTRT for 3 or more blanks (as it won't recursively > apply the change to a *new* double blank formed by the previous change). echo 'a b' | tr -s ' ' | cut -d' ' -f2 b that is the light way ;-) Alejandro Mery [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/x-pkcs7-signature, Size: 5013 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-04 1:36 ` Rob Landley 2009-01-04 5:07 ` Valdis.Kletnieks @ 2009-01-04 7:15 ` Michal Jaegermann 1 sibling, 0 replies; 47+ messages in thread From: Michal Jaegermann @ 2009-01-04 7:15 UTC (permalink / raw) To: Rob Landley Cc: Ingo Oeser, Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Sat, Jan 03, 2009 at 07:36:04PM -0600, Rob Landley wrote: > On Saturday 03 January 2009 06:28:22 Ingo Oeser wrote: > > > +for i in "MSEC 1000" "USEC 1000000" > > > +do > > > + NAME=$(echo $i | awk '{print $1}') > > > > cut -d' ' -f1 does the same > > > > > + PERIOD=$(echo $i | awk '{print $2}') > > > > cut -d' ' -f2 does the same > > From a standards perspective > http://www.opengroup.org/onlinepubs/9699919799/utilities/cut.html vs > http://www.opengroup.org/onlinepubs/9699919799/utilities/awk.html is probably > a wash, but from a simplicity perspective using the tool that _isn't_ its own > programming language is probably a win. :) Vagaries of 'cut' aside you can limit yourself here to just shell: set_name_period () { NAME=$1 ; PERIOD=$2 } for i in "MSEC 1000" "USEC 1000000" do set_name_period $i .... done or you may skip a shell function and do 'set $i' within a loop plus assignments of $1 and $2 to NAME and PERIOD but that overwrites original positional parameters (which may be already not important). Michał ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-02 8:13 ` [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley 2009-01-02 9:04 ` Sam Ravnborg 2009-01-03 12:28 ` Ingo Oeser @ 2009-01-05 0:41 ` Ray Lee 2009-01-05 5:08 ` Rob Landley 2 siblings, 1 reply; 47+ messages in thread From: Ray Lee @ 2009-01-05 0:41 UTC (permalink / raw) To: Rob Landley Cc: Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Fri, Jan 2, 2009 at 12:13 AM, Rob Landley <rob@landley.net> wrote: > 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. Nice work. As the computations can all be done in 64-bit precision now, and there have been concerns expressed about some shells not supporting 64 bit integers, is there any reason this can't be done using long longs in C? Other than ruining a good bike shed argument, anyway. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh 2009-01-05 0:41 ` Ray Lee @ 2009-01-05 5:08 ` Rob Landley 0 siblings, 0 replies; 47+ messages in thread From: Rob Landley @ 2009-01-05 5:08 UTC (permalink / raw) To: Ray Lee Cc: Embedded Linux mailing list, linux-kernel, Andrew Morton, H. Peter Anvin, Sam Ravnborg On Sunday 04 January 2009 18:41:15 Ray Lee wrote: > On Fri, Jan 2, 2009 at 12:13 AM, Rob Landley <rob@landley.net> wrote: > > 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. > > Nice work. Thanks. You'll definitely want to look at the _second_ version of that patch rather than the first, though. :) > As the computations can all be done in 64-bit precision > now, and there have been concerns expressed about some shells not > supporting 64 bit integers, is there any reason this can't be done > using long longs in C? Nope. Any of this could be done in C. (And that's the approach Sam Ravnborg prefers to take for the second patch in the series, upgrading unifdef.c to do everything itself.) I tend to lean towards scripts that create header files rather than programs that create header files, but as long as you remember to use HOSTCC it's fairly straightforward. :) > Other than ruining a good bike shed argument, anyway. Oh pile on. It beats being dismissed as the only one on the planet who cares about the issue (again). :) Rob ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2009-12-12 0:49 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-12-08 9:17 [PATCH 0/3] clean out Perl from build system Rob Landley 2009-12-08 9:19 ` [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley 2009-12-09 15:45 ` Michal Marek 2009-12-09 23:40 ` Rob Landley 2009-12-09 23:45 ` H. Peter Anvin 2009-12-10 1:50 ` Rob Landley 2009-12-10 1:53 ` H. Peter Anvin 2009-12-10 13:52 ` Michal Marek 2009-12-10 23:16 ` Rob Landley 2009-12-11 15:31 ` Michal Marek 2009-12-11 19:13 ` H. Peter Anvin 2009-12-12 0:49 ` Rob Landley 2009-12-08 9:21 ` [PATCH 2/3] Remove perl from make headers_install Rob Landley 2009-12-08 9:22 ` [PATCH 3/3] Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh Rob Landley 2009-12-08 10:23 ` [PATCH 0/3] clean out Perl from build system Michal Marek 2009-12-08 15:08 ` Rob Landley -- strict thread matches above, loose matches on Subject: below -- 2009-09-19 1:25 [PATCH 0/3] Perl removal patches for 2.6.31 Rob Landley 2009-09-19 1:33 ` [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley 2009-01-02 8:07 PATCH [0/3]: Simplify the kernel build by removing perl Rob Landley 2009-01-02 8:13 ` [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh Rob Landley 2009-01-02 9:04 ` Sam Ravnborg 2009-01-02 12:00 ` Rob Landley 2009-01-02 19:33 ` H. Peter Anvin 2009-01-04 1:32 ` Rob Landley 2009-01-04 1:35 ` H. Peter Anvin 2009-01-04 12:07 ` Alan Cox 2009-01-04 18:36 ` H. Peter Anvin 2009-01-04 19:03 ` Rob Landley 2009-01-04 20:39 ` H. Peter Anvin 2009-01-05 0:59 ` Rob Landley 2009-01-03 6:28 ` Harvey Harrison 2009-01-03 12:28 ` Ingo Oeser 2009-01-04 1:36 ` Rob Landley 2009-01-04 5:07 ` Valdis.Kletnieks 2009-01-04 6:43 ` Rob Landley 2009-01-04 22:13 ` Jamie Lokier 2009-01-05 0:15 ` Bernd Petrovitsch 2009-01-05 2:23 ` Jamie Lokier 2009-01-05 10:46 ` Bernd Petrovitsch 2009-01-05 15:01 ` Jamie Lokier 2009-01-05 16:18 ` Bernd Petrovitsch 2009-01-06 0:06 ` Rob Landley 2009-01-05 21:07 ` Rob Landley 2009-01-05 4:50 ` Rob Landley 2009-01-05 12:29 ` Bernd Petrovitsch 2009-01-04 21:51 ` Alejandro Mery 2009-01-04 7:15 ` Michal Jaegermann 2009-01-05 0:41 ` Ray Lee 2009-01-05 5:08 ` Rob Landley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).