lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 2 Jan 2009 06:56:31 -0600
From:	Rob Landley <rob@...dley.net>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Arkadiusz Miskiewicz <a.miskiewicz@...il.com>,
	linux-kernel@...r.kernel.org,
	Embedded Linux mailing list <linux-embedded@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Sam Ravnborg <sam@...nborg.org>
Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl.

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 <strike>morning</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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ