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

2009-01-02 Thread Rob Landley
From: Rob Landley r...@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.

Peter Anvin added this perl to 2.6.25.  Before that, the kernel had never
required perl to build.

Signed-off-by: Rob Landley r...@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.0 -0600
+++ hg/kernel/timeconst.sh  2009-01-01 23:53:17.0 -0600
@@ -0,0 +1,91 @@
+#!/bin/bash
+
+if [ $# -ne 1 ]
+then
+   echo Usage: timeconst.sh HZ
+   exit 1
+fi
+
+HZ=$1
+
+# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit math.
+
+[ $((132)) -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 100
+do
+   NAME=$(echo $i | awk '{print $1}')
+   PERIOD=$(echo $i | awk '{print $2}')
+
+   # Find greatest common denominator (using Euclid's algorithm)
+
+   A=$HZ
+   B=$PERIOD
+
+   while [ $B -ne 0 ]
+   do
+   C=$(($A%$B))
+   A=$B
+   B=$C
+   done
+
+   GCD=$A
+
+   # Do this for each direction (HZ_TO_PERIOD and PERIOD_TO_HZ)
+
+   for DIRECTION in 0 1
+   do
+   if [ $DIRECTION -eq 0 ]
+   then
+   CONVERT=HZ_TO_${NAME}
+   FROM=$HZ
+   TO=$PERIOD
+   else
+   CONVERT=${NAME}_TO_HZ
+   FROM=$PERIOD
+   TO=$HZ
+   fi
+
+   # How many shift bits give 32 bits of significant data?
+
+   SHIFT=0
+   while [ $(( (($TO$SHIFT)+$FROM-1)/$FROM )) -lt $((131)) ]
+   do
+   SHIFT=$(( $SHIFT+1 ))
+   done
+
+   MUL32=$(( (($TO$SHIFT)+$FROM-1)/$FROM ))
+   MUL32=$(printf %x $MUL32)
+   echo #define ${CONVERT}_MUL32  U64_C(0x$MUL32)
+   ADJ32=$(($FROM/$GCD))
+   ADJ32=$(( (($ADJ32-1)$SHIFT)/$ADJ32 ))
+   ADJ32=$(printf %x $ADJ32)
+   echo #define ${CONVERT}_ADJ32  U64_C(0x$ADJ32)
+   echo #define ${CONVERT}_SHR32  $SHIFT
+   echo #define ${CONVERT}_NUMU64_C($(($TO/$GCD)))
+   echo #define ${CONVERT}_DENU64_C($(($FROM/$GCD)))
+   done
+done
+
+echo
+echo #endif /* KERNEL_TIMECHONST_H */
--- hg/kernel/timeconst.pl  2008-11-22 19:09:13.0 -0600
+++ /dev/null   1969-12-31 00:00:00.0 -0600
@@ -1,378 +0,0 @@
-#!/usr/bin/perl
-# ---
-#
-#   Copyright 2007-2008 rPath, Inc. - All Rights Reserved
-#
-#   This file is part of the Linux kernel, and is made available under
-#   the terms of the GNU General Public License version 2 or (at your
-#   option) any later version; incorporated herein by reference.
-#
-# ---
-#
-
-#
-# Usage: timeconst.pl HZ  timeconst.h
-#
-
-# Precomputed values for systems without Math::BigInt
-# Generated by:
-# timeconst.pl --can 24 32 48 64 100 122 128 200 250 256 300 512 1000 1024 1200
-%canned_values = (
-   24 = [
-   '0xa6ab','0x2aa',26,
-   125,3,
-   '0xc49ba5e4','0x1fbe76c8b4',37,
-   3,125,
-   '0xa2c2aaab','0x',16,
-   125000,3,
-   '0xc9539b89','0x7fffbce4217d',47,
-   3,125000,
-   ], 32 = [
-   '0xfa00','0x600',27,
-   125,4,
-   '0x83126e98','0xfdf3b645a',36,
-   4,125,
-   '0xf424','0x0',17,
-   31250,1,
-   '0x8637bd06','0x3fff79c842fa',46,
-   1,31250,
-   ], 48 = [
-   '0xa6ab','0x6aa',27,
-   125,6,
-   '0xc49ba5e4','0xfdf3b645a',36,

[PATCH 3/3]: Convert mkcapflags.pl to mkcapflags.sh

2009-01-02 Thread Rob Landley
From: Rob Landley r...@landley.net

Convert kernel/cpu/mkcapflags.pl to kernel/cpu/mkcapflags.sh.

This script generates kernel/cpu/capflags.c from include/asm/cpufeature.h.

Peter Anvin added this perl to 2.6.28.

Signed-off-by: Rob Landley r...@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 alt-linux/arch/x86/kernel/cpu/Makefile 
alt-linux2/arch/x86/kernel/cpu/Makefile
--- alt-linux/arch/x86/kernel/cpu/Makefile  2008-12-24 17:26:37.0 
-0600
+++ alt-linux2/arch/x86/kernel/cpu/Makefile 2008-12-28 18:10:51.0 
-0600
@@ -23,10 +23,10 @@
 obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o
 
 quiet_cmd_mkcapflags = MKCAP   $@
-  cmd_mkcapflags = $(PERL) $(srctree)/$(src)/mkcapflags.pl $ $@
+  cmd_mkcapflags = $(CONFIG_SHELL) $(srctree)/$(src)/mkcapflags.sh $ $@
 
 cpufeature = $(src)/../../include/asm/cpufeature.h
 
 targets += capflags.c
-$(obj)/capflags.c: $(cpufeature) $(src)/mkcapflags.pl FORCE
+$(obj)/capflags.c: $(cpufeature) $(src)/mkcapflags.sh FORCE
$(call if_changed,mkcapflags)
diff -ruN alt-linux/arch/x86/kernel/cpu/mkcapflags.pl 
alt-linux2/arch/x86/kernel/cpu/mkcapflags.pl
--- alt-linux/arch/x86/kernel/cpu/mkcapflags.pl 2008-12-24 17:26:37.0 
-0600
+++ alt-linux2/arch/x86/kernel/cpu/mkcapflags.pl1969-12-31 
18:00:00.0 -0600
@@ -1,32 +0,0 @@
-#!/usr/bin/perl
-#
-# Generate the x86_cap_flags[] array from include/asm-x86/cpufeature.h
-#
-
-($in, $out) = @ARGV;
-
-open(IN,  $in\0)   or die $0: cannot open: $in: $!\n;
-open(OUT,  $out\0) or die $0: cannot create: $out: $!\n;
-
-print OUT #include 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 alt-linux/arch/x86/kernel/cpu/mkcapflags.sh 
alt-linux2/arch/x86/kernel/cpu/mkcapflags.sh
--- alt-linux/arch/x86/kernel/cpu/mkcapflags.sh 1969-12-31 18:00:00.0 
-0600
+++ alt-linux2/arch/x86/kernel/cpu/mkcapflags.sh2008-12-28 
18:08:50.0 -0600
@@ -0,0 +1,28 @@
+#!/bin/bash
+#
+# Generate the x86_cap_flags[] array from include/asm/cpufeature.h
+#
+
+IN=$1
+OUT=$2
+
+(
+   echo #include 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...@.*/\* 
*\([^]*\).*\*/@\...@p')
+   [ -z $VALUE ]  VALUE=\$(echo $NAME | tr A-Z a-z)\
+
+   [ $VALUE != '' ]  echo   [X86_FEATURE_$NAME] = $VALUE,
+   done
+   echo };
+)  $OUT



Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Arkadiusz Miskiewicz
On Friday 02 of January 2009, Rob Landley wrote:
 Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 )
 building a Linux kernel never required perl to be installed on the build
 system.  (Various development and debugging scripts were written in perl
 and python and such, but they weren't involved in actually building a
 kernel.) Building a kernel before 2.6.25 could be done with a minimal
 system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux
 kernel, and nothing else.

And now bash is going to be required... while some distros don't need/have 
bash. /bin/sh should be enough.

Heh,
-- 
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Christoph Hellwig
On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
 On Friday 02 of January 2009, Rob Landley wrote:
  Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 )
  building a Linux kernel never required perl to be installed on the build
  system.  (Various development and debugging scripts were written in perl
  and python and such, but they weren't involved in actually building a
  kernel.) Building a kernel before 2.6.25 could be done with a minimal
  system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux
  kernel, and nothing else.
 
 And now bash is going to be required... while some distros don't need/have 
 bash. /bin/sh should be enough.

*nod*  bash is in many ways a worse requirement than perl.  strict posix
/bin/sh + awk + sed would be nicest, but if that's too much work perl
seems reasonable.

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Mark Miller


On Jan 2, 2009, at 3:26 AM, Arkadiusz Miskiewicz wrote:


On Friday 02 of January 2009, Rob Landley wrote:
Before 2.6.25 (specifically git  
bdc807871d58285737d50dc6163d0feb72cb0dc2 )
building a Linux kernel never required perl to be installed on the  
build
system.  (Various development and debugging scripts were written in  
perl

and python and such, but they weren't involved in actually building a
kernel.) Building a kernel before 2.6.25 could be done with a minimal
system built from gcc, binutils, bash, make, busybox, uClibc, and  
the Linux

kernel, and nothing else.


And now bash is going to be required... while some distros don't  
need/have

bash. /bin/sh should be enough.


Which distros only have /bin/sh which do not have Perl? I'm honestly  
curious.



--
Arkadiusz MiśkiewiczPLD/Linux Team
arekm / maven.plhttp://ftp.pld-linux.org/


--
Mark Miller
m...@mirell.org




--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Alejandro Mery
Christoph Hellwig escribió:
 On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
   
 On Friday 02 of January 2009, Rob Landley wrote:
 
 Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2 )
 building a Linux kernel never required perl to be installed on the build
 system.  (Various development and debugging scripts were written in perl
 and python and such, but they weren't involved in actually building a
 kernel.) Building a kernel before 2.6.25 could be done with a minimal
 system built from gcc, binutils, bash, make, busybox, uClibc, and the Linux
 kernel, and nothing else.
   
 And now bash is going to be required... while some distros don't need/have 
 bash. /bin/sh should be enough.
 

 *nod*  bash is in many ways a worse requirement than perl.  strict posix
 /bin/sh + awk + sed would be nicest, but if that's too much work perl
 seems reasonable.
well, bash is not worse as bash is trivial to cross-compile to run on a
constrained sandbox and perl is a nightmare, but I agree bash should be
avoided too.

I think the $(( ... )) bash-ism can be replaced with a simple .c helper toy.

Thank Rob for reopening the topic.

Alejandro Mery



smime.p7s
Description: S/MIME Cryptographic Signature


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Paul Mundt
On Fri, Jan 02, 2009 at 04:32:42AM -0600, Mark Miller wrote:
 On Jan 2, 2009, at 3:50 AM, Paul Mundt wrote:
 Misguided rhetoric aside, what does this actually accomplish? If folks
 add meaningful tools in to the kernel that require python, and it is
 generally regarded as being fairly ubiquitous, I can't imagine there
 being any substantiated objections against it.
 
 And if the said meaningful tools introduce complex dependencies, then  
 there should be an open discussion as to why exactly we need those  
 tools as opposed to a simpler implementation.
 
Complex is relative, something that is fairly ubiquitious can hardly be
labelled as complex, regardless of whether historically people have had
issues with that dependency in certain spaces. In any event, simplifying
things is always good, but this open discussion thing is pure fancy,
since when was the kernel a democracy?

 Your main reasons against inclusion of perl seem to be that there is
 no realistic expectation for target systems that will be self-hosting
 will have perl included, or the inherent complexity in maintaining a
 coherent cross compiling environment. Both of these things are issues
 with your own environment, and in no way are these representative of
 the  embedded development community at large.
 
 I feel that if you attempted to look for discussions on cross- 
 compiling perl, you will meet with a variety of complaints on what a  
 nightmare it is to do so in a sandboxed environment.
 
I've had to deal with cross compiling perl for over a decade, in all of
its various forms, in all manner of embedded applications, so please tell
someone who cares. There are various options around this headache today,
as there have been for ages (though the options these days are rather
less painful), and if you felt like attempting to look for discussions on
those rather than trying to push this silly matter perhaps you might come
up with something.

The key thing you hit on is that there are a variety of complaints, and
that is all they have ever been. If your system is so constrained, you
shouldn't be doing builds on it in the first place. You certainly won't
be able to build anything in your crippled environment outside of some
simple applications anyways, this isn't a valid technical reason for
keeping the kernel a policy stranglehold.

 Now with that out of the way, this entire series fundamentally fails
 to convert half of the perl scripts shipped with the kernel today,
 some that are required for build depending on Kconfig options,
 
[snip]

 From what I can tell, it allows one to fully build the Linux kernel  
 without Perl.

Wrong, re-read what I said and try again.

 Ignoring the compile-time dependencies that you overlooked, what you
 define as development and debugging scripts are still an integral  
 part of the system, unless you are trying to argue that embedded
 developers have no interest in things like checkstack due to the
 trouble of trying to get perl built.
 
 Do I need that to compile a kernel? No.
 
Compile-time dependencies you do, yes.

 Perl was not required to build the Linux kernel. Now it is. It adds  
 another dependency to the Linux kernel. Requiring bash is far less a  
 dependency that Perl is.
 
Perhaps so, but that is largely irrelevant. Moving off of the bash
dependency is a lot more trivial than moving off of the perl one. The
kernel bashisms are fairly marginal, and if someone were to do the leg
work for that, it might even be accepted. Getting rid of perl is an
uphill battle for no visible gain. People will continue to write and add
scripts both in bash and perl on a routine basis regardless.

 The kernel is and always has been about using the right tool for the  
 job, not a matter of dictating what tools you must use in order to
 accomplish a task you are interested in. Common sense does apply here
 though, so this might be a more daunting task for some than others.
 
 How is Perl a better tool for the job than what currently bash and  
 other standard utilities already offer?
 
How is bash a better tool for than job than what sed and posix shell
already offer? Yes, we can reduce our dependencies to the bare minimum,
but that is not constructive for the folks that are actually writing the
scripts in the first place.

Likewise, this is not even a real problem in the embedded developer
demographic, the only place this is a problem is in specially stripped
distributions or people that don't want to go through the pain of cross
compiling perl. None of which is of any concern.

If people are going to write useful things that are reasonably expected
to be standard on build machines, there is no reason to restrict what
tools they are permitted to use. If you have a personal vendetta against
something that is fairly standard, that is entirely your own personal
problem, you can choose to deal with it or patch out of tree for your own
crippled environment (assuming patch isn't too much of an obscure
dependency).
--
To 

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Rob Landley
On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote:
 On Friday 02 of January 2009, Rob Landley wrote:
  Before 2.6.25 (specifically git bdc807871d58285737d50dc6163d0feb72cb0dc2
  ) building a Linux kernel never required perl to be installed on the
  build system.  (Various development and debugging scripts were written in
  perl and python and such, but they weren't involved in actually building
  a kernel.) Building a kernel before 2.6.25 could be done with a minimal
  system built from gcc, binutils, bash, make, busybox, uClibc, and the
  Linux kernel, and nothing else.

 And now bash is going to be required... while some distros don't need/have
 bash. /bin/sh should be enough.

 Heh,

I believe all three scripts run under dash and busybox ash.  (The timeconst.sh 
one needs 64 bit math which dash only provides on 64 bit hosts, which is a 
regression from Red Hat 9 in 2003 by the way.  Busybox ash can also provide 64 
bit math on 32 bit hosts, and the script should run with that just fine if you 
haven't got bash and that's what your sh in the path is.)

The makefiles execute those scripts via CONFIG_SHELL, not via the #!/blah line 
at the start, so it's largely irrelevant what gets put there anyway.  If you 
haven't got bash installed it'll use sh, which should work with dash on a 64 
bit host or with busybox ash.  (That's why that one file has a test to make 
sure 64 bit math _does_ work.  The only Linux development environment I'm 
aware of where that test would trigger is if you use a 32 bit ubuntu and go 
out of your way to _uninstall_ bash.  Even Cygwin uses bash.)

Beyond that, find linux -type f | xargs grep bin/bash | wc comes up with 38 
instances (admittedly half of 'em in Documentation, but lots in scripts, and 
makefiles, and defconfigs, at least one hardwired in C code.)  So this would 
not a _new_ dependency.

By the way, what Linux distros install a compiler toolchain but not bash?  I'm 
curious.  (Even after Ubuntu moved #!/bin/sh to point to dash, it still 
installs bash as part of the default environment, even if you don't install 
development tools.)  You've built the kernel on this system before?

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Rob Landley
On Friday 02 January 2009 04:16:53 Alejandro Mery wrote:
 Christoph Hellwig escribió:
  On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
  On Friday 02 of January 2009, Rob Landley wrote:
  Before 2.6.25 (specifically git
  bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel
  never required perl to be installed on the build system.  (Various
  development and debugging scripts were written in perl and python and
  such, but they weren't involved in actually building a kernel.)
  Building a kernel before 2.6.25 could be done with a minimal system
  built from gcc, binutils, bash, make, busybox, uClibc, and the Linux
  kernel, and nothing else.
 
  And now bash is going to be required... while some distros don't
  need/have bash. /bin/sh should be enough.
 
  *nod*  bash is in many ways a worse requirement than perl.  strict posix
  /bin/sh + awk + sed would be nicest, but if that's too much work perl
  seems reasonable.

 well, bash is not worse as bash is trivial to cross-compile to run on a
 constrained sandbox and perl is a nightmare, but I agree bash should be
 avoided too.

 I think the $(( ... )) bash-ism can be replaced with a simple .c helper
 toy.

No, $[ ] is the bashism, $(( )) is susv3:
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04

I intentionally switched from $[ ] to $(( )) to make dash work.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-01-02 Thread 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 r...@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 r...@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.0 -0600
  +++ hg/kernel/timeconst.sh  2009-01-01 23:53:17.0 -0600
  @@ -0,0 +1,91 @@
  +#!/bin/bash
  +
  +if [ $# -ne 1 ]
  +then
  +   echo Usage: timeconst.sh HZ
  +   exit 1
  +fi

 That usage is useless. Either extend it or spend a few lines
 in the shell script explainign what the shell script is supposed to do.

Do you mean something more like:

echo Usage: timeconst.sh HZ
echo
echo Generates a header file of constants for converting between decimal
echo HZ timer ticks and milisecond or microsecond delays

I'm happy turning it into a comment instead, I just found a quick check that 
I'd remembered to type an argument useful during debugging. :)

  +
  +HZ=$1
  +
  +# Sanity test: even the shell in Red Hat 9 (circa 2003) supported 64 bit
  math. +
  +[ $((132)) -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 100
  +do
  +   NAME=$(echo $i | awk '{print $1}')
  +   PERIOD=$(echo $i | awk '{print $2}')
  +
  +   # Find greatest common denominator (using Euclid's algorithm)
  +
  +   A=$HZ
  +   B=$PERIOD
  +
  +   while [ $B -ne 0 ]
  +   do
  +   C=$(($A%$B))
  +   A=$B
  +   B=$C
  +   done
  +
  +   GCD=$A
  +
  +   # Do this for each direction (HZ_TO_PERIOD and PERIOD_TO_HZ)
  +
  +   for DIRECTION in 0 1
  +   do
  +   if [ $DIRECTION -eq 0 ]
  +   then
  +   CONVERT=HZ_TO_${NAME}
  +   FROM=$HZ
  +   TO=$PERIOD
  +   else
  +   CONVERT=${NAME}_TO_HZ
  +   FROM=$PERIOD
  +   TO=$HZ
  +   fi
  +
  +   # How many shift bits give 32 bits of significant data?
  +
  +   SHIFT=0
  +   while [ $(( (($TO$SHIFT)+$FROM-1)/$FROM )) -lt $((131)) ]
  +   do
  +   SHIFT=$(( $SHIFT+1 ))
  +   done
  +
  +   MUL32=$(( (($TO$SHIFT)+$FROM-1)/$FROM ))
  +   MUL32=$(printf %x $MUL32)
  +   echo #define ${CONVERT}_MUL32  U64_C(0x$MUL32)
  +   ADJ32=$(($FROM/$GCD))
  +   ADJ32=$(( (($ADJ32-1)$SHIFT)/$ADJ32 ))
  +   ADJ32=$(printf %x $ADJ32)
  +   echo #define ${CONVERT}_ADJ32  U64_C(0x$ADJ32)
  +   echo #define ${CONVERT}_SHR32  $SHIFT
  +   echo #define ${CONVERT}_NUMU64_C($(($TO/$GCD)))
  +   echo #define ${CONVERT}_DENU64_C($(($FROM/$GCD)))
  +   done
  +done

 Is it a shell limitation that all spaces around operators are missing?
 Makes it hard to read..

No, I was just trying to make sure I didn't go over the 80 char limit.  
(Several temporary variables are there primarily because 

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Mark Miller

On Jan 2, 2009, at 4:57 AM, Paul Mundt wrote:


On Fri, Jan 02, 2009 at 04:32:42AM -0600, Mark Miller wrote:

On Jan 2, 2009, at 3:50 AM, Paul Mundt wrote:
Misguided rhetoric aside, what does this actually accomplish? If  
folks

add meaningful tools in to the kernel that require python, and it is
generally regarded as being fairly ubiquitous, I can't imagine there
being any substantiated objections against it.


And if the said meaningful tools introduce complex dependencies, then
there should be an open discussion as to why exactly we need those
tools as opposed to a simpler implementation.

Complex is relative, something that is fairly ubiquitious can hardly  
be
labelled as complex, regardless of whether historically people have  
had
issues with that dependency in certain spaces. In any event,  
simplifying

things is always good, but this open discussion thing is pure fancy,
since when was the kernel a democracy?


I'm ignoring the bait.


Your main reasons against inclusion of perl seem to be that there is
no realistic expectation for target systems that will be self- 
hosting

will have perl included, or the inherent complexity in maintaining a
coherent cross compiling environment. Both of these things are  
issues

with your own environment, and in no way are these representative of
the  embedded development community at large.


I feel that if you attempted to look for discussions on cross-
compiling perl, you will meet with a variety of complaints on what a
nightmare it is to do so in a sandboxed environment.

I've had to deal with cross compiling perl for over a decade, in all  
of
its various forms, in all manner of embedded applications, so please  
tell

someone who cares.


Ignoring this as well.


There are various options around this headache today,
as there have been for ages (though the options these days are rather
less painful), and if you felt like attempting to look for  
discussions on
those rather than trying to push this silly matter perhaps you might  
come

up with something.


And ignoring this too.

The key thing you hit on is that there are a variety of complaints,  
and

that is all they have ever been. If your system is so constrained, you
shouldn't be doing builds on it in the first place. You certainly  
won't

be able to build anything in your crippled environment outside of some
simple applications anyways, this isn't a valid technical reason for
keeping the kernel a policy stranglehold.


I merely don't like seeing another dependency added when there's no  
logical reason to do it, other than why not. And there have been  
reasons given for the not. Your reply, seems merely to be, Because.




Now with that out of the way, this entire series fundamentally fails
to convert half of the perl scripts shipped with the kernel today,
some that are required for build depending on Kconfig options,



[snip]


From what I can tell, it allows one to fully build the Linux kernel
without Perl.


Wrong, re-read what I said and try again.


I have done so. And I restate, without these patches, Perl is required  
*for any install*. Your logic seems to be, if Perl is required for any  
part of doing something with the Linux kernel, then there is no reason  
it should not be allowed in all parts.


With this logic, soon the Linux kernel will require so many  
dependencies, that even a minimal system to rebuild itself under  
itself will comprise 200MB for stripped binaries. Right now, it's down  
to about 20ish.


With that, you also require more expertise in maintaing these variety  
of tools. You have given no logical reason on why we need to add more  
complexity to the kernel, when previous tools have managed to deal  
with this task for over ten years without requiring Perl.



Ignoring the compile-time dependencies that you overlooked, what you
define as development and debugging scripts are still an integral
part of the system, unless you are trying to argue that embedded
developers have no interest in things like checkstack due to the
trouble of trying to get perl built.


Do I need that to compile a kernel? No.


Compile-time dependencies you do, yes.


Perl was not required to build the Linux kernel. Now it is. It adds
another dependency to the Linux kernel. Requiring bash is far less a
dependency that Perl is.


Perhaps so, but that is largely irrelevant. Moving off of the bash
dependency is a lot more trivial than moving off of the perl one. The
kernel bashisms are fairly marginal, and if someone were to do the leg
work for that, it might even be accepted. Getting rid of perl is an
uphill battle for no visible gain. People will continue to write and  
add

scripts both in bash and perl on a routine basis regardless.


The kernel is and always has been about using the right tool for the
job, not a matter of dictating what tools you must use in order to
accomplish a task you are interested in. Common sense does apply  
here

though, so this might be a more daunting task for 

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Rob Landley
On Friday 02 January 2009 03:50:23 Paul Mundt wrote:
 On Fri, Jan 02, 2009 at 02:07:28AM -0600, Rob Landley wrote:
  The perl checkin for 2.6.25 was the camel's nose under the tent flap, and
  since then two more instances of perl have shown up in the core kernel
  build. This patch series removes the three required to build a basic
  kernel for qemu for the targets I've tested (arm, mips, powerpc, sparc,
  m68k, sh4, and of course x86 and x86-64), replacing them with shell
  scripts.

 Misguided rhetoric aside, what does this actually accomplish? If folks
 add meaningful tools in to the kernel that require python, and it is
 generally regarded as being fairly ubiquitous, I can't imagine there
 being any substantiated objections against it.

I think bloat-o-meter is a marvelous tool, and I'm a big fan of python.  But I 
don't think you shouldn't have to run that to compile a kernel either, largely 
because not needing it for the first 17 years or so implied living without 
this requirement could be done, sustainably even.

There's a difference between a development workstation and a dedicated build 
system.  Requiring you to install X11 plus qt on the headless build server 
cranking out nightly snapshots in order to run the configure stage of the 
kernel build would be silly.  But this is not an argument for ripping out 
make xconfig from the kernel.

Spot the difference?

 Your main reasons against inclusion of perl seem to be that there is no
 realistic expectation for target systems that will be self-hosting will
 have perl included, or the inherent complexity in maintaining a coherent
 cross compiling environment.

I'm saying it's a major new environmental dependency that went in fairly 
recently and largely without comment, and it causes real world headaches for 
real people, of which I am only one.

If you don't think environmental dependencies are a problem, I welcome you to 
attempt to build open office.  (Even the gentoo guys gave up on that one and 
just started shipping a prebuilt binary.)

I think large amounts of complexity start with small amounts of complexity 
that grow.  Complexity is inevitable, but there should be a _reason_ for 
increases in it.

 Both of these things are issues with your
 own environment, and in no way are these representative of the embedded
 development community at large.

 Now with that out of the way, this entire series fundamentally fails to
 convert half of the perl scripts shipped with the kernel today, some that
 are required for build depending on Kconfig options, and others that are
 simply useful tools for self-hosted environments.

I didn't say the job was finished.  These are just the ones I've already 
personally hit, and thus A) needed to rewrite to build the kernel in my build 
environment, B) have a handy test case for.

 Simply converting a
 couple of scripts over you find objectionable is certainly fine if there
 is a real benefit in doing so, but this doesn't actually accomplish your
 goal of removing the perl dependency.

A) It's a start.

B) It works for me, and builds the .configs I've personally needed so far.

 Ignoring the compile-time dependencies that you overlooked, what you
 define as development and debugging scripts are still an integral part
 of the system, unless you are trying to argue that embedded developers
 have no interest in things like checkstack due to the trouble of trying
 to get perl built.

Coming up with new patches and modifying the source is a different use for 
source code than going ./configure; make; make install.  This is true for 
most open source software, I'd expect.

Or are you implying that eclipse or Emacs are such great IDEs that being able 
to build outside of a GUI isn't interesting?  The ability to build within an 
IDE should be allowed to preclude the ability to build without one?

 Until you can post a series that converts all of scripts/*.pl in its
 entirety, you have failed to address the fundamental reason why perl is
 used in the first place.

Never start anything unless you can finish it all in one go, eh?

Last I heard the kernel guys tend to frown on people who wander off in their 
own corner for a year and then dump a massive rewrite on them.  They seem to 
prefer the incremental trail of breadcrumbs approach.  Release early, 
release often, incorporate feedback, keep at it.

Or am I wrong?

 Trying to toss bizarre policy statements around
 regarding things you personally find objectionable without any coherent
 technical argument to the contrary is of no constructive use whatsoever.

Complexity is a cost, environmental dependencies are a form of complexity, if 
the benefit isn't worth the cost (or you can get the benefit without the cost) 
then you shouldn't pay the cost.

I was unaware this was a controversial attitude?

 The kernel is and always has been about using the right tool for the job,
 not a matter of dictating what tools you must use in order to accomplish
 a task you are 

Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Rob Landley
On Friday 02 January 2009 03:49:34 Christoph Hellwig wrote:
 On Fri, Jan 02, 2009 at 10:26:37AM +0100, Arkadiusz Miskiewicz wrote:
  On Friday 02 of January 2009, Rob Landley wrote:
   Before 2.6.25 (specifically git
   bdc807871d58285737d50dc6163d0feb72cb0dc2 ) building a Linux kernel
   never required perl to be installed on the build system.  (Various
   development and debugging scripts were written in perl and python and
   such, but they weren't involved in actually building a kernel.)
   Building a kernel before 2.6.25 could be done with a minimal system
   built from gcc, binutils, bash, make, busybox, uClibc, and the Linux
   kernel, and nothing else.
 
  And now bash is going to be required... while some distros don't
  need/have bash. /bin/sh should be enough.

 *nod*  bash is in many ways a worse requirement than perl.  strict posix
 /bin/sh + awk + sed would be nicest, but if that's too much work perl
 seems reasonable.

The scripts should work with dash (modulo the one that needs 64 bit math, 
which dash only provides on a 64 bit host), or with busybox ash (which can 
provide 64 bit math on 32 bit hosts just like bash can).  I'll explicitly 
retest both of those when I respin the patches in the strikemorning/strike 
afternoon.

(And yes I thought about writing my own arbitrary precision arithmetic shell 
functions, but it really didn't seem worth the complexity since the only 32 
bit Linux distros I've seen that install dash also install bash by default.  I 
just put in a test for 32 bit math so it can spot it and fail, on the off 
chance you're running a 32 bit host with dash after explicitly uninstalling 
bash.  All the embedded 32 bit ones that try to act as development 
environments use busybox ash, or more often just install bash.)

That said, how is bash _worse_ than perl?  (Where's the second implementation 
of perl?  Even Python had jython, but perl has... what?  The attempt to rebase 
on Parrot went down in flames...)

If the argument is that depending on a specific shell implementation is as 
bad as depending on the one and only implementation of perl, that argument I 
can at least follow, even if it doesn't actually apply in this case.  But 
where does worse come in?

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Theodore Tso
On Fri, Jan 02, 2009 at 06:56:31AM -0600, Rob Landley wrote: 
 That said, how is bash _worse_ than perl?  (Where's the second
 implementation of perl?  Even Python had jython, but perl
 has... what?  The attempt to rebase on Parrot went down in
 flames...)

(1) bash implies POSIX extensions; perl is actually quite portable.

(2) There are distributions that install with perl by default but not
bash; they use dash for speed reasons.

Sounds like though modulo dealing with 64-bit arithmetic, your patches
are mostly dash/POSIX.2 comformant, so you're probably mostly good on
that front once you address the 32/64-bit issues.  I'd also suggest
explicitly add a reminder to the shell scripts' comments to avoid
bashisms for maximum portability, to remind developers in the future
who might try to change the shell scripts to watch out for portability
issues.

- Ted

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Matthieu CASTET
Rob Landley a écrit :
 On Friday 02 January 2009 03:26:37 Arkadiusz Miskiewicz wrote:
 On Friday 02 of January 2009, Rob Landley wrote:

 Heh,
 
 I believe all three scripts run under dash and busybox ash.  (The 
 timeconst.sh 
 one needs 64 bit math which dash only provides on 64 bit hosts, which is a 
 regression from Red Hat 9 in 2003 by the way.
With dash 0.5.4-12 (from debian sid), I seems I got the 64 bit math for
32 bit hosts :
$ uname -m
i686
$ dash -c 'echo $((132))'
4294967296


Matthieu
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Wookey
On 2009-01-02 18:50 +0900, Paul Mundt wrote:
 Your main reasons against inclusion of perl seem to be that there is no
 realistic expectation for target systems that will be self-hosting will
 have perl included, or the inherent complexity in maintaining a coherent
 cross compiling environment. Both of these things are issues with your
 own environment, and in no way are these representative of the embedded
 development community at large.

It may well be true that most embedded people cross-build kernels and
use native perl on a fat build box, but there are plenty of situations
where being able to build kernels without perl is useful. Given the
simplicitly of these patches I can't see any reason not to put them
in, and appreciate Rob's work on this.

And if cross-building perl is really easy, as some in this thread
claim, can someone fix the Debian packages to do it, because that
would be really useful (it appears to be of similar complexity to
cross-building gcc, requiring a 2-stage self-referential build). 

Wookey
-- 
Principal hats:  Balloonz - Toby Churchill - Aleph One - Debian
http://wookware.org/
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread Sam Ravnborg
Hi Wookey.

 Given the
 simplicitly of these patches I can't see any reason not to put them
 in

Please do NOT do the mistake and think this the same thing.

Rob's patch simplyfy the timecost stuff - and will be applied on
this merit alone assuming comments will be addressed.

But the serie rased anohter topic: shall we ban use of perl
for generating a kernel.
And this is what primary is discussed and the outcome of
that discussion will not prevent patches that stands on their
own to be applied.

Sam
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PATCH [0/3]: Simplify the kernel build by removing perl.

2009-01-02 Thread H. Peter Anvin
Sam Ravnborg wrote:
 Hi Wookey.
 
 Given the
 simplicitly of these patches I can't see any reason not to put them
 in
 
 Please do NOT do the mistake and think this the same thing.
 
 Rob's patch simplyfy the timecost stuff - and will be applied on
 this merit alone assuming comments will be addressed.
 
 But the serie rased anohter topic: shall we ban use of perl
 for generating a kernel.
 And this is what primary is discussed and the outcome of
 that discussion will not prevent patches that stands on their
 own to be applied.
 

My personal opinion on this is that this is ridiculous.  Given that you
need gcc, binutils, make etc. to build the kernel, and this is more than
inherent, you have to have a pretty bloody strangely constrained system
to disallow Perl, which is as close to a standard Unix utility you can
get without making it into SuS.

The only *real* motivation I have seen for this is a system that as far
I can tell is nothing other than a toy, specifically designed to show
off how little you need to build the kernel.  In other words, it's not a
practical application, it's a show-off art piece.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-01-02 Thread 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.

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-01-02 Thread 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

--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html