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: <c384c5ea0901031637k3b571313m934c8881dce1c81@mail.gmail.com>
Date:	Sun, 4 Jan 2009 01:37:12 +0100
From:	"Leon Woestenberg" <leon.woestenberg@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Rob Landley" <rob@...dley.net>,
	"Embedded Linux mailing list" <linux-embedded@...r.kernel.org>,
	linux-kernel@...r.kernel.org,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Sam Ravnborg" <sam@...nborg.org>
Subject: Re: PATCH [0/3]: Simplify the kernel build by removing perl.

Hello,

On Sun, Jan 4, 2009 at 12:03 AM, H. Peter Anvin <hpa@...or.com> wrote:
>> Dependencies very quickly become dependency hell. If A requires B,
>> then A also inherits all (future) requirements of B, etc. etc.
>>
>> In my daily software development work with Linux and GNU software in
>> general, 10% of it is spent fighting/removing these extremely "thin"
>> or false depencies, so that it is usuable in embedded devices.
>>
>
> First of all, I largely consider this a joke.  All real-life embedded
> kernel builds take place on hosted platforms; anything else seems to be
> done "just because it can be done", as a kind of show-off art project.
> Cute, but hardly worth impeding the rest of the kernel community for.
>
Let me explain why it is not a joke for me, although yes I agree it's
a funny way of how software engineering works.

My argument on thin dependencies indeed mostly holds for run-time
dependencies (to reduce size) but also for build dependency (to reduce
complexity)*.

In general the right version of the right tool is not available on the
build host.

If I cross-build 30 packages all of which need a build-host-native
perl during their build, consider the chance of these packages
building with the one version of perl that lives on the system. It's
near 0% for the average mix of packages.

Yes, the host is fat enough so that we can build (say three) different
versions of perl to accomodate the build.

The truth often is, of the 30 build dependencies 25 of them are thin
(build) dependencies.

So yes, the say extra 10% of build tool dependency needed to make 0.5%
of the build system work, can be solved on the fat build platform, but
I do not always consider it a well engineered solution.

For a (dangerous) metaphor: In mechanical engineering, if there are 30
joints using nuts and bolts, and a 31st is designed in, it is strongly
prefered to make it a nut and bolt as well, even if using a screw
would work equally well or even better. The overall costs (over
complexity, tool dependency, maintainability) would be lower.

Regards,
-- 
Leon

* Since Intel, since recently, pays another team of excellent people
maintaining a system dealing with the (cross) build tool dependency
hell, I rest my case. :-)
--
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/