linux-kernel - Re: [REGRESSION] Recent change to kernel spikes out ccache/distcc

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:	Wed, 7 Jan 2009 05:10:27 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Jan Beulich <jbeulich@...ell.com>, Sam Ravnborg <sam@...nborg.org>,
	linux-kernel@...r.kernel.org, ccache@...ts.samba.org
Subject: Re: [REGRESSION] Recent change to kernel spikes out ccache/distcc

On Tue, Jan 06, 2009 at 10:15:26AM -0500, Theodore Ts'o wrote:
> Or, if that's too complicated, maybe it would be worthwhile to have
> kbuild create its own specialized ccache system?  Note that the last two
> solutions rule out using distcc, unless we can encapsulate the build
> process from a series of Makefile macros to a shell or C program, which
> could then be injected to the remote host system to be executed by
> distcc.  One value of doing that is the CRC or MD5 of the shell script
> could be used as the version tag for the cache system.

Ho-hum...  Could somebody explain why the hell had we switched to this
"intermediate .s" approach, anyway?  It's not as if we couldn't run
objcopy after what we used to do...

BTW, do we care about non-ELF targets at all?
--
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/