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

[Rob Landley <rob@landley.net>]

On Friday 02 January 2009 12:01:34 Sam Ravnborg wrote:
> But the serie rased anohter topic: shall we ban use of perl
> for generating a kernel.

I dunno about "ban", but every time somebody adds perl to the "hot path" of 
the kernel build it breaks my build system, and I write a removal patch 
anyway.  I have to maintain them anyway, so I might as well try to push 'em 
upstream.  (I posted the first patch in this series twice before, once for 25 
and then an updated version to the linux-embedded list for .26.)

I didn't discover this topic independently.  Somebody pinged me about it on 
freenode back in February, and several other people sent me private email 
about it, and it's been previously raised on several other mailing lists (such 
as busybox and uclibc ones).

Unfortunately, most of the embedded developers I know aren't subscribed to 
linux-kernel.  (You either do kernel development, or you do everything else.  
It's not really feasible to keep up with the guts of the kernel and uClibc and 
busybox and gcc and qemu and the current offerings of three different hardware 
vendors and whatever userspace application the board's supposed to run and 
your build system and what INSANE things your EEdiot electrical engineer 
decided to miswire this time and fighting off marketing's desire to switch 
everything over to WinCE because they can get their entire advertising budget 
subsidized and there's a trade show next week we're not READY for...  Not only 
can none of 'em read a meaningful subset of linux-kernel anymore, but if you 
disappear into your own little niche for nine months, when you pop back up the 
kernel's all different and sometimes even the patch submission policy's 
migrated a bit.  Heck, I'm three months behind reading the LWN kernel page 
myself, and that's no substitute for kernel-traffic, RIP...)

Hopefully the cc: to linux-embedded is helping get more embedded guys involved 
in the discussion than just me. :)

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

The best way to get a patch applied is always for that patch to stand on its 
own merits.  Larger agendas are secondary.

Whether or not the kernel decides on a policy of keeping perl out of the 
kernel build's "hot path", I still need these patches for my own use, and plan 
to keep coming up with them and submitting them.  I haven't removed ones that 
haven't broken my build yet, but just because I'm not using md today doesn't 
mean I won't _start_.  (And if enough other people keep poking me about the 
kernel build I can tackle 'em to please them.  I actually _do_ know some 
embedded developers using raid for network attached storage and video servers 
and such...)

> 	Sam

Rob