linux-kernel - Re: CONFIG_KPROBES=y build requires gawk

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: <4B299AB5.7020109@zytor.com>
Date:	Wed, 16 Dec 2009 18:43:01 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Roland Dreier <rdreier@...co.com>
CC:	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>,
	Rob Landley <rob@...dley.net>
Subject: Re: CONFIG_KPROBES=y build requires gawk

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.

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.  Personally I think a dependency on Perl is better than the
mess we're in; I understand other people disagree.  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.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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