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

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]

Message-Id: <200901031935.10968.rob@landley.net>
Date:	Sat, 3 Jan 2009 19:35:10 -0600
From:	Rob Landley <rob@...dley.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	Embedded Linux mailing list <linux-embedded@...r.kernel.org>,
	Paul Mundt <lethal@...ux-sh.org>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl.

On Friday 02 January 2009 13:27:45 H. Peter Anvin wrote:
> 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,

I believe Intel's icc builds the kernel, and tinycc previously built a subset 
of the kernel.  The pcc and llvm/clang projects are getting close to being 
able to build the kernel.  Ever since c99 came out, lots of gcc-isms with c99 
equivalents have been swapped over, most of the rest is testing.

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

Please show me A) the standard perl implements, B) the second implementation 
of that standard ala IETF guidelines.

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

I'm glad you think my Firmware Linux project is a work of art, but if you'd 
like to hear directly from my users I can ask them to complain at you in 
person, if you like.  I'm not sure what that would prove, though.

When cross compiling, it's good to have as constrained an environment as 
possible, because otherwise bits of the host system leak into the target 
system.  If you don't tightly control your cross compiling environment, it 
won't work.  That's just about an axiom in embedded development.

I know every single dependency my system has.  I can list them, explicitly.  I 
did this because it's very _USEFUL_ in this context.

Add perl scripts that call cpan, and this is no longer true.

> 	-hpa

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/