Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark Miller
Date: Fri Jan 02 2009 - 05:33:00 EST
On Jan 2, 2009, at 3:50 AM, Paul Mundt wrote:
On Fri, Jan 02, 2009 at 02:07:28AM -0600, Rob Landley wrote:
Before 2.6.25 (specifically git
bdc807871d58285737d50dc6163d0feb72cb0dc2 )
building a Linux kernel never required perl to be installed on the
build
system. (Various development and debugging scripts were written in
perl and
python and such, but they weren't involved in actually building a
kernel.)
Building a kernel before 2.6.25 could be done with a minimal system
built from
gcc, binutils, bash, make, busybox, uClibc, and the Linux kernel,
and nothing
else. (Embedded developers creating clean cross compile
environments that
won't leak bits of the host system into the target, or
bootstrapping native
development environments to run on target hardware or under
emulators, tend to
care about this sort of thing.)
The perl checkin for 2.6.25 was the camel's nose under the tent
flap, and
since then two more instances of perl have shown up in the core
kernel build.
This patch series removes the three required to build a basic
kernel for qemu
for the targets I've tested (arm, mips, powerpc, sparc, m68k, sh4,
and of
course x86 and x86-64), replacing them with shell scripts.
Misguided rhetoric aside, what does this actually accomplish? If folks
add meaningful tools in to the kernel that require python, and it is
generally regarded as being fairly ubiquitous, I can't imagine there
being any substantiated objections against it.
And if the said meaningful tools introduce complex dependencies, then
there should be an open discussion as to why exactly we need those
tools as opposed to a simpler implementation.
Your main reasons against inclusion of perl seem to be that there is
no
realistic expectation for target systems that will be self-hosting
will
have perl included, or the inherent complexity in maintaining a
coherent
cross compiling environment. Both of these things are issues with your
own environment, and in no way are these representative of the
embedded
development community at large.
I feel that if you attempted to look for discussions on "cross-
compiling perl", you will meet with a variety of complaints on what a
nightmare it is to do so in a sandboxed environment.
Now with that out of the way, this entire series fundamentally fails
to
convert half of the perl scripts shipped with the kernel today, some
that
are required for build depending on Kconfig options, and others that
are
simply useful tools for self-hosted environments. Simply converting a
couple of scripts over you find objectionable is certainly fine if
there
is a real benefit in doing so, but this doesn't actually accomplish
your
goal of removing the perl dependency.
From what I can tell, it allows one to fully build the Linux kernel
without Perl. Without these series of patches, to actually *build* the
kernel, one requires Perl. Unless there is an alternate way to do
"make headers_install" that I am not seeing, that appears to now be
done in Perl. All the other Perl scripts were merely nice to have, not
necessary to build a Linux kernel.
Ignoring the compile-time dependencies that you overlooked, what you
define as "development and debugging" scripts are still an integral
part
of the system, unless you are trying to argue that embedded developers
have no interest in things like checkstack due to the trouble of
trying
to get perl built.
Do I need that to compile a kernel? No.
Until you can post a series that converts all of scripts/*.pl in its
entirety, you have failed to address the fundamental reason why perl
is
used in the first place. Trying to toss bizarre policy statements
around
regarding things you personally find objectionable without any
coherent
technical argument to the contrary is of no constructive use
whatsoever.
Perl was not required to build the Linux kernel. Now it is. It adds
another dependency to the Linux kernel. Requiring bash is far less a
dependency that Perl is.
The kernel is and always has been about using the right tool for the
job,
not a matter of dictating what tools you must use in order to
accomplish
a task you are interested in. Common sense does apply here though, so
this might be a more daunting task for some than others.
How is Perl a better tool for the job than what currently bash and
other standard utilities already offer?
--
Mark Miller
mark@xxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/