Use sed instead of perl to generate x86/kernel/cpu/capflags.c.
PATCH 1/1 Use sed instead of perl to generate x86/kernel/cpu/capflags.c.
From: Rob Landley <[email protected]>
Generate capflags.c with sed (POSIX 2008) instead of perl.
---
This patch hasn't changed since 2009.
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(-)
arch/x86/kernel/cpu/Makefile +2 -2
@@ -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)
arch/x86/kernel/cpu/mkcapflags.pl +0 -32
@@ -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);
arch/x86/kernel/cpu/mkcapflags.sh +28 -0
@@ -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
Quoted 4 lines · Rob Landley
From: Rob Landley <[email protected]>
Generate
capflags.cwith sed (POSIX 2008) instead of perl.
While I'm not personally a great perl fan, this still begs the question, why?
We already depend on perl for other stuff, so why replace something that works with something that may or may not work?
Signature · 3 lines
Jesper Juhl <[email protected]> http://www.chaosbits.net/ Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please.
Quoted 9 lines · Jesper Juhl
Quoted 4 lines · Rob Landley
From: Rob Landley <[email protected]>
Generate
capflags.cwith sed (POSIX 2008) instead of perl.While I'm not personally a great perl fan, this still begs the question, why?
1) In general, simpler is better. (Why ship autoconf files to build on hosts that don't have autoconf? Why fix make oldconfig so it builds on platforms that don't have curses installed?)
2) Making reliable cross compile build environments involves creating a known build environment on the host, generally removing everything you don't actually _need_ so it can't screw things up when you introduce another target or upgrade packages on your host.
I've maintained such a build environment (aboriginal linux) for several years. I've personally encountered literally _dozens_ of others, and expect there are at least hundreds if not thousands out in the wild.
3) Perl is not a well-defined langauge. It is a single implementation, not a standard. (Like Microsoft Word and Excel, their file formats are just "what this program emits/parses". Similarly, Perl is what the perl binary runs. Attemts to rewrite it based on Parrot famously collapsed into a black hole of corner cases.)
Meaning, if you have a platform on which the one and only implementation of perl doesn't run, you have no alternative implementations to try. (Did I mention that Perl's configuration stage is implemented in perl?)
This moves to an alternative standardized by POSIX, which has well understood behavior with multiple independent implementations (gnu, bsd, busybox...)
Quoted 2 lines
We already depend on perl for other stuff, so why replace something that works with something that may or may not work?
We have various development scripts that depend on perl, curses, python, QT, and so on. But building a _kernel_ doesn't depend on any of that... except perl. I'm not proposing removing checkstack.pl and such, because "development system" != "build machine". A build machine can be a headless box, a development system usually has things like Gnome or KDE installed.
The kernel's dependency on Perl was introduced in 2.6.25. Before 2008 the kernel built just fine on a host that didn't have perl installed, and I've been patching the kernel to remove the requirement ever since in my own build environment. (And building the resulting kernel for a dozen different targets, and submitting those patches here when they changed. They just haven't changed in a while.)
Perl is used in exactly three places during the kernel build. I have patches to remove the other two instances of perl use, and using them have built a kernel on a system that doesn't have perl installed. I'm tweaking them for submission later today. My prevoius submissions (such as http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/00148.html)
treated them as a series, but since the three issues are really orthogonal I'm posting them individually this time, and cc-ing the various people get_maintainer.pl says to.
Rob
Quoted 55 lines · Rob Landley
Quoted 9 lines · Jesper Juhl
Quoted 4 lines · Rob Landley
From: Rob Landley <[email protected]>
Generate
capflags.cwith sed (POSIX 2008) instead of perl.While I'm not personally a great perl fan, this still begs the question, why?
1) In general, simpler is better. (Why ship autoconf files to build on hosts that don't have autoconf? Why fix make oldconfig so it builds on platforms that don't have curses installed?)
2) Making reliable cross compile build environments involves creating a known build environment on the host, generally removing everything you don't actually _need_ so it can't screw things up when you introduce another target or upgrade packages on your host.
I've maintained such a build environment (aboriginal linux) for several years. I've personally encountered literally _dozens_ of others, and expect there are at least hundreds if not thousands out in the wild.
3) Perl is not a well-defined langauge. It is a single implementation, not a standard. (Like Microsoft Word and Excel, their file formats are just "what this program emits/parses". Similarly, Perl is what the perl binary runs. Attemts to rewrite it based on Parrot famously collapsed into a black hole of corner cases.)
Meaning, if you have a platform on which the one and only implementation of perl doesn't run, you have no alternative implementations to try. (Did I mention that Perl's configuration stage is implemented in perl?)
This moves to an alternative standardized by POSIX, which has well understood behavior with multiple independent implementations (gnu, bsd, busybox...)
Quoted 2 lines
We already depend on perl for other stuff, so why replace something that works with something that may or may not work?
We have various development scripts that depend on perl, curses, python, QT, and so on. But building a _kernel_ doesn't depend on any of that... except perl. I'm not proposing removing checkstack.pl and such, because "development system" != "build machine". A build machine can be a headless box, a development system usually has things like Gnome or KDE installed.
The kernel's dependency on Perl was introduced in 2.6.25. Before 2008 the kernel built just fine on a host that didn't have perl installed, and I've been patching the kernel to remove the requirement ever since in my own build environment. (And building the resulting kernel for a dozen different targets, and submitting those patches here when they changed. They just haven't changed in a while.)
Quoted 9 lines
Perl is used in exactly three places during the kernel build. I have patches to remove the other two instances of perl use, and using them have built a kernel on a system that doesn't have perl installed. I'm tweaking them for submission later today. My prevoius submissions (such as http://lkml.indiana.edu/hypermail/linux/kernel/0901.0/00148.html)
treated them as a series, but since the three issues are really orthogonal I'm posting them individually this time, and cc-ing the various people get_maintainer.pl says to.
Thanks a lot for spelling out the reasons.
Those are good reasons in my opinion. I'll test your changes once all 3 are posted and if things still work I'll be sure to reply with a
Tested-by: to help things along.
Signature · 3 lines
Jesper Juhl <[email protected]> http://www.chaosbits.net/ Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please.
From: Rob Landley <[email protected]>
Replace perl header file generator with smaller/faster/simpler C version.
---
I ran the attached test script to compare the output of the C program with the output of the perl version for every HZ from 1 to 5000 to make sure it was producing the same constants.
kernel/Makefile | 10 - kernel/mktimeconst.c | 109 +++++++++++ kernel/timeconst.pl | 378 ----------------------------------------- 3 files changed, 115 insertions(+), 382 deletions(-)
kernel/Makefile +6 -4
@@ -133,8 +133,10 @@ $(obj)/config_data.h: $(obj)/config_data.gz FORCE $(obj)/time.o: $(obj)/timeconst.h -quiet_cmd_timeconst = TIMEC $@ - cmd_timeconst = $(PERL) $< $(CONFIG_HZ) > $@ +hostprogs-y += mktimeconst +quiet_cmd_mktimeconst = TIMEC $@ + cmd_mktimeconst = $(obj)/mktimeconst $(CONFIG_HZ) $@ || ( rm -f $@ && exit 1 ) + targets += timeconst.h -$(obj)/timeconst.h: $(src)/timeconst.pl FORCE - $(call if_changed,timeconst) +$(obj)/timeconst.h: $(obj)/mktimeconst FORCE + $(call if_changed,mktimeconst)
kernel/mktimeconst.c new file +109 -0
109 lines not on this page · raw message
kernel/timeconst.pl deleted +0 -378
378 lines not on this page · raw message
Quoted 6 lines · Rob Landley
From: Rob Landley <[email protected]>
Replace perl header file generator with smaller/faster/simpler C version.
Signed-off-by Rob Landley <[email protected]>
Pretty nice!
One small problem below.
Quoted 5 lines
I ran the attached test script to compare the output of the C program with the output of the perl version for every HZ from 1 to 5000 to make sure it was producing the same constants.
I think you can use diff to compare the perl output and C output, with different HZ values.
kernel/mktimeconst.c line 108
Quoted 6 lines
kernel/mktimeconst.c new file +6
-0+fprintf (file,"#endif /* __KERNEL_TIMECONST_H */\n" ); + +/* Notice if the disk fills up. */ + +fflush (stdout); +return ferror (stdout);
Why do you fflush stdout while you are writing to 'file'?
Thanks.