From owner-freebsd-current@FreeBSD.ORG Fri Nov 16 10:59:30 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D897DE35 for ; Fri, 16 Nov 2012 10:59:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 164758FC15 for ; Fri, 16 Nov 2012 10:59:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA14860; Fri, 16 Nov 2012 12:59:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZJdp-0001BM-0i; Fri, 16 Nov 2012 12:59:21 +0200 Message-ID: <50A61C88.9040203@FreeBSD.org> Date: Fri, 16 Nov 2012 12:59:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Daniel Braniss Subject: Re: compiler info in kernel identification string References: <20121113234303.GA15319@dft-labs.eu> <50A3639C.9050200@FreeBSD.org> <1352907497.1217.147.camel@revolution.hippie.lan> <50A57623.4020108@FreeBSD.org> <50A5EC7C.5050303@FreeBSD.org> <5B4DE1FD-5DD3-49A5-B8DB-6D4C03ABD742@cederstrand.dk> <50A606E7.5000302@FreeBSD.org> <50A612F9.30509@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Erik Cederstrand X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 10:59:31 -0000 on 16/11/2012 12:54 Daniel Braniss said the following: >> >> This is starting to turn into a bikeshed, but anyway... >> >> on 16/11/2012 12:00 Daniel Braniss said the following: >>> the question as to what compiler was used to compile the kernel is a bit of an >>> oxymoron, since the kernel is made up of many different modules, which get >>> compiled >>> either by different compilers, or different compiler flags. >> >> The canonical way to compile a kernel is to use buildkernel and compile modules > > this does not guarantee uniformity, just look at the output it produces and > you will see > different compilers/assemblers/scripts/flags Different flags specified in the build infrastructure are OK. >> along with the kernel. Other configurations are supported too, of course. >> > >>> since the compiler does 'sign' the modules it compiles (and clang will/should >>> do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like >>> file(1) could be modified to provide it, or config -x (8) ... >> >> The key word in your note about clang is 'soon' as in 'not yet'. > Dimitry wrote that he will handle it :-) Right. 'will' is not 'did'. >> >> Besides, when I see a bug report with a dmesg *I* want to immediately know what >> compiler was used there. > today it's clang vs. gcc -- transition time --, but again it's only part of > the story, > and soon it will only be noise. Different kernel toolchains are here to stay. And it's not just clang vs gcc, but also different toolchains for embedded world, etc. -- Andriy Gapon