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

Rob Landley
2009-01-03T19:49:01Z

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