[PATCH 0/3] clean out Perl from build system.

[PATCH 0/3] clean out Perl from build system.

[Rob Landley]

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

[PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

[PATCH 2/3] Remove perl from make headers_install

[Rob Landley]

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

[PATCH 3/3] Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh

[Rob Landley]

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

Re: [PATCH 0/3] clean out Perl from build system.

[Michal Marek]

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

Re: [PATCH 0/3] clean out Perl from build system.

[Rob Landley]

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

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[Michal Marek]

[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

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[H. Peter Anvin]

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

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[H. Peter Anvin]

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

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[Michal Marek]

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

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[Michal Marek]

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

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[H. Peter Anvin]

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.

Re: [PATCH 1/3] Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

[PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Bernd Petrovitsch]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Jamie Lokier]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Bernd Petrovitsch]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Bernd Petrovitsch]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Jamie Lokier]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Ray Lee]

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.

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Bernd Petrovitsch]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Jamie Lokier]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Alejandro Mery]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[H. Peter Anvin]

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.

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[H. Peter Anvin]

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.

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Alan Cox]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Michal Jaegermann]

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ł

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Valdis.Kletnieks]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[H. Peter Anvin]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Ingo Oeser]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Harvey Harrison]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[H. Peter Anvin]

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.

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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

Re: [PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Sam Ravnborg]

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

[PATCH 1/3]: Replace kernel/timeconst.pl with kernel/timeconst.sh

[Rob Landley]

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¥