Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754020AbZALKhq (ORCPT ); Mon, 12 Jan 2009 05:37:46 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751861AbZALKhg (ORCPT ); Mon, 12 Jan 2009 05:37:36 -0500 Received: from mta23.gyao.ne.jp ([125.63.38.249]:21559 "EHLO mx.gate01.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750698AbZALKhf (ORCPT ); Mon, 12 Jan 2009 05:37:35 -0500 Date: Mon, 12 Jan 2009 19:34:43 +0900 From: Paul Mundt To: "Mark A. Miller" Cc: Bernd Petrovitsch , Leon Woestenberg , Rob Landley , "H. Peter Anvin" , Embedded Linux mailing list , linux-kernel@vger.kernel.org, Andrew Morton , Sam Ravnborg Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl. Message-ID: <20090112103443.GE28564@linux-sh.org> Mail-Followup-To: Paul Mundt , "Mark A. Miller" , Bernd Petrovitsch , Leon Woestenberg , Rob Landley , "H. Peter Anvin" , Embedded Linux mailing list , linux-kernel@vger.kernel.org, Andrew Morton , Sam Ravnborg References: <495FEEAF.5020005@zytor.com> <200901032006.47652.rob@landley.net> <20090104030619.GA21466@linux-sh.org> <1231677939.3517.5.camel@gimli.at.home> <31014a580901111936q41486efagcb90af2b6880a470@mail.gmail.com> <20090112082058.GB28564@linux-sh.org> <31014a580901120118u55256b51g448f22e9e0ef5d1f@mail.gmail.com> <20090112094121.GD28564@linux-sh.org> <31014a580901120203v593ce9bdn6876263770efbeae@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31014a580901120203v593ce9bdn6876263770efbeae@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2197 Lines: 39 On Mon, Jan 12, 2009 at 04:03:32AM -0600, Mark A. Miller wrote: > On Mon, Jan 12, 2009 at 3:41 AM, Paul Mundt wrote: > > I will repeat, there has not been a single coherent argument against what > > makes perl inherently incapable of being supported. > > You're right, this thread is worthless with that particular mindset, > Paul. Not, perhaps that the tool in question is brittle, and prone to > potentially break on more architectures than the current make and C > code infrastructure, no, your stance is, unless Perl *cannot* run on > that particular architecture and environment, it has a valid place in > the kernel because it was chosen by certain developers. > Nonsense. I singled out that point because that was the one you were replying to in the first place. I itemized the objections in this thread earlier on and attempted to indicate why they were not applicable in this context, and asked people to add to it if anything had been overlooked. If you want to play semantics, do it somewhere else. If the tool is brittle and constantly breaking, we will see bug reports, and re-evaluate the support position. This hasn't happened to date in the context of the kernel build system, so there is no point in even bringing this up. Anyways, given that you haven't contributed anything to the kernel and are therefore perhaps unfamiliar with how things work, I attempted to show you why the kernel made the decision it did and what it would take to change that. You have from the beginning only wanted to focus on idle semantics and refused to re-evaluate your own position on what precisely it is you find to be problematic in the first place. So, with that, I am done with this thread, and it seems the key takeaways from this entire thing has only been a few new lines in my killfile. It's regrettable you didn't get anything else out of this thread, though I think both the kernel and embedded linux will survive. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/