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]
Date:	Sat, 3 Jan 2009 20:06:47 -0600
From:	Rob Landley <rob@...dley.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Leon Woestenberg <leon.woestenberg@...il.com>,
	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.

On Saturday 03 January 2009 17:03:11 H. Peter Anvin wrote:
> Leon Woestenberg wrote:
> > I agree with Rob that the amount of required dependencies should be
> > kept to a minimum.
> >
> > If we only use 0.5% of a certain language (or: dependent package),
> > then rather implement that 0.5% in the existing language.
> >
> > 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.

Yes, I've noticed this.  The fact multiple other people do _not_ consider this 
a joke doesn't seem to have sunk in yet.

> 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.
>
> We're not talking about general platform dependencies here, but build
> dependencies for the kernel.  A platform that can build the kernel is
> not a small platform.

The kernel didn't need perl to build until 2.6.25.  For 17 years, this 
dependency was not required.  You added it, in a way that affected even 
"allnoconfig", for no obvious gain.

> Second of all, these patches are not fullworthy replacements.  The
> original patch using bc had less dependencies, but bc failed on some
> platforms, mysteriously.

So rather than debugging it, you rewrote it in perl.  Much less potential 
mysterious behavior there.

> The new patches have *more* environmental
> dependencies than that ever did.

Could you please be a little more specific?

> Third, if someone actually cares to do it right, I have a smallish
> bignum library at http://git.zytor.com/?p=lib/pbn.git;a=summary that
> might be a starting point.

This doesn't _need_ bignum support.  It maxes out around 72 bits and the 
_result_ can't use more than about $SHIFT bits because you're dividing by the 
amount you shifted, so just chop off the bottom 32 bits, do a normal 64 bit 
division on the top (it has to fit), and then do the same division on the 
appropriate shifted remainder, and combine the results.  This is easy because 
when the shift _is_ 32 bits or more, the bottom 32 bits all have to be zeroes 
so you don't even have to mask and add, just shift the remainder left 32 bits 
so you can continue the divide.

Pulling out perl isn't always a good alternative to thinking about the 
problem.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ