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: <200912162209.29744.rob@landley.net>
Date:	Wed, 16 Dec 2009 22:09:28 -0600
From:	Rob Landley <rob@...dley.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Roland Dreier <rdreier@...co.com>,
	Andrew Isaacson <adi@...are.com>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
	Masami Hiramatsu <mhiramat@...hat.com>
Subject: Re: CONFIG_KPROBES=y build requires gawk

On Wednesday 16 December 2009 20:43:01 H. Peter Anvin wrote:
> On 12/16/2009 05:39 PM, Roland Dreier wrote:
> > Is there any reason not to apply the patch below, to allow more awk
> > implementations to be used?  After all, it's not like we're going to put
> > non-ASCII characters into the map file...
>
> I guess the question is if it will break under any other circumstances,
> but I guess we can find those when we get to them.
>
> There was a long discussion about the use of awk on IRC today.
> Apparently mawk, in particular, is actively broken, because the
> maintainer believe that POSIX is crap.  There are quite a few issues
> with it, according to reports.

if the kernel specifies posix, and that implementation doesn't do posix, then 
that implementation doesn't build the kernel.  Blacklisting known broken 
implementations makes a certain amount of sense.

> We need a sane scripting language available to the kernel build, and
> given all the problems we have had with different versions or even just
> sometimes different builds of sh, awk, and even bc -- plus the fact that
> those utilities just don't necessarily do what we want makes it very
> frustrating.

1) Posix exists for a reason.

2) Busybox implements what the kernel has needed to build.  (I test this every 
release, and I fix it where necessary.)

> Personally I think a dependency on Perl is better than the
> mess we're in; I understand other people disagree.

Vehemently.

> What is definitely
> not acceptable, however, is the status quo.  The situation is, quite
> frankly, ridiculous enough that perhaps the right thing to do is to
> write a small scripting engine and bundle it with the kernel.  Something
> that does what we need it to do, but is only one implementation and
> something we can extend at will if need be.

*shrug*  That's one way to avoid environmental dependencies.

> 	-hpa

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
--
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