From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52117C433B4 for ; Mon, 3 May 2021 09:26:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1C6EE61221 for ; Mon, 3 May 2021 09:26:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233095AbhECJ1B (ORCPT ); Mon, 3 May 2021 05:27:01 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:54297 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231531AbhECJ1A (ORCPT ); Mon, 3 May 2021 05:27:00 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]) by mrelayeu.kundenserver.de (mreue106 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MFspV-1lmdVZ06bn-00HLv6; Mon, 03 May 2021 11:26:06 +0200 Received: by mail-wm1-f44.google.com with SMTP id i128so918590wma.5; Mon, 03 May 2021 02:26:05 -0700 (PDT) X-Gm-Message-State: AOAM532/q9G146qrkVL/mfrZW70yKi+6l1Zlx7XSvGHsAPiGMVXCn68f 41sWx97x3zwPypWOvC1Fjk4mQuX1U9PYEhYqjcQ= X-Google-Smtp-Source: ABdhPJyImR0lXDOWh/rFmKSSJQOuX4SzDcgMMWQ8OtmjXS6cOp8lf5wEACKwu1MdktyqNDYlMn4UdggeZ8LLn0fAS0M= X-Received: by 2002:a7b:c344:: with SMTP id l4mr30642981wmj.120.1620033965603; Mon, 03 May 2021 02:26:05 -0700 (PDT) MIME-Version: 1.0 References: <20210501151538.145449-1-masahiroy@kernel.org> <3943bc020f6227c8801907317fc113aa13ad4bad.camel@perches.com> <20210502183030.GF10366@gate.crashing.org> <81a926a3bdb70debe3ae2b13655ea8d249fb9991.camel@perches.com> <20210502203253.GH10366@gate.crashing.org> <20210502223007.GZ1847222@casper.infradead.org> In-Reply-To: From: Arnd Bergmann Date: Mon, 3 May 2021 11:25:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Raise the minimum GCC version to 5.2 To: Matthew Wilcox , Linus Torvalds , Segher Boessenkool , Joe Perches , Miguel Ojeda , Masahiro Yamada , Albert Ou , Arnd Bergmann , Linux Kbuild mailing list , Greg Kroah-Hartman , Jonathan Corbet , Linux Doc Mailing List , linux-kernel , Palmer Dabbelt , Paul Walmsley , Catalin Marinas , Miguel Ojeda , Paul Mackerras , linux-riscv , linuxppc-dev , Will Deacon , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:I/gsU3RbqaIRE+KdOLKT4bEkOO4frLNAEzQL12xugLqWiiJxUqo ZqghVLMD/GUpTP4K38iEuh9Sfiy5CCwVV18DD937YPcFl/NYol0MHqUOoJAeI9GRipH6RCQ rNNVp6g/4xhZJnewZxlGDYgFJFAvTflxs6mTgf8Ccuv/J6+jN73IZ7ufQBMUQJ2wF5E0H8T 2Xh+GD0sFyVuKr4w25OXQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:qdR9Si/Ru1A=:7j1bygQueRVWljbbzNPkyF ad5Pd/8bG5uytvKX8LkT3utJfYUm3W/5y3mllEvsU3k0+DzTbZ8KUuULWnkbvah+EeeEaG89U yD3pbzGHpbhSxIl9vrooM6/7tEwC6ixZBXr/b6V9L/hhlqnMUOgne7ZCnGqjJU5YxcY7BCRyQ mTAoIN9eusOwJZiiNi30SToBv20+IDLkCQOx5ivtuAypz/1LNEaaRUT3lMmX+EdA7CDD6Vzz0 mjpqEKxd9rTJ9/w8Abnu7LrlB4/DU8h42gulxxZQcAAmT+yV5DhLZmZ8+L2InBj5Na40QQrPl JP2krHBJA+Q95+FDLJBzhWQs2AGVI4WDsih1HlBStSQwu1gPKwz2J3F9SILvanGcdhwFXs0sV EfWcXHvmyyqhWniu8M2V/J8oGmDB9M/iJUJmtJ6ys+ww8t8BSH9Azi1t9PfWtW0Nzw+lLUo09 awJVfYOUAs6QqMiEfaqZrl+otdBGNfir6D7sZVWBGQ5MkRL0n/O3/BD/9C3P+AeeSPgGibbE9 TGun0Wcy1UNCDKqjzdU7R2BjmcPiCS94+8FumZbLrI9AS0+SdocVypRQ+OrSW8C0FkzG4Q9yG 5AZKhopNGwzf90XIokEWNN5X7cucuwxYu1q4PAWPC8C6/MiTRvgPKnQiMfZ/rACo8f8X0vLf6 jqLY= Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 3, 2021 at 9:35 AM Alexander Dahl wrote: > > Desktops and servers are all nice, however I just want to make you > aware, there are embedded users forced to stick to older cross > toolchains for different reasons as well, e.g. in industrial > environment. :-) > > This is no show stopper for us, I just wanted to let you be aware. Can you be more specific about what scenarios you are thinking of, what the motivations are for using an old compiler with a new kernel on embedded systems, and what you think a realistic maximum time would be between compiler updates? One scenario that I've seen previously is where user space and kernel are built together as a source based distribution (OE, buildroot, openwrt, ...), and the compiler is picked to match the original sources of the user space because that is best tested, but the same compiler then gets used to build the kernel as well because that is the default in the build environment. There are two problems I see with this logic: - Running the latest kernel to avoid security problems is of course a good idea, but if one runs that with ten year old user space that is never updated, the system is likely to end up just as insecure. Not all bugs are in the kernel. - The same logic that applies to ancient user space staying with an ancient compiler (it's better tested in this combination) also applies to the kernel: running the latest kernel on an old compiler is something that few people test, and tends to run into more bugs than using the compiler that other developers used to test that kernel. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BAB9C433ED for ; Mon, 3 May 2021 09:26:40 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4830A61244 for ; Mon, 3 May 2021 09:26:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4830A61244 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WcLj81ye/sALtMI8Q1wtT0V6DS6k/sGXwCLBndy6ql0=; b=ZNSPL05YhH7zFN +GJjASkFzICsfD66mQ/Fpa6ZEwKHPT1TjuM2X+cU2HkYDfmDAu9QiOWBUM7MryNQQ/QZrXPTPlv81 1NhqIjv9CNeWI+imJdBaX5FObVhueQE/HRHr95mDfVQ4L2Rzw4PUel4XgtVkN/kfzG8anGhqJWk4K 7dbL+QFocCGGVrkAsJQY7iQqxiwPN0c6a3rDTZWzdGZE0xOtK+EG/Oz6h6160eBJskTjemc8wd2DI D9wz549NRqt5azQXS++M7EyeFvvGtEejUTsyGFrgoCt10EVttu3vatLWcTVPMYCMrlY2Qubnwnr6F RFcKQYujR+PR9qfF9FfQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1ldUqL-00DX9S-LP; Mon, 03 May 2021 09:26:21 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ldUqE-00DX93-Ca; Mon, 03 May 2021 09:26:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:To:Subject:Message-ID: Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=fLy9DiO4d7hbeLXoGuF654ufloNHLfA8Z/WN8IvEIrw=; b=kE/KWJcXUMDiX/bLnTIIk8V3EZ RDQi4rzJ1j/t3S+F1r5KI6oW3iLmtpur+TSElahzOdrDxSqqZ+6hxmw9vW+UiXGyfT5vooXS9txxs YdXy/9aoUppEx4211oc/14RI8P1yNGsXiOluhKWCJXylihLWa2xo/SlSSZRR9+xTk6/+BlLlz1vsJ lBDnTc6hu9TUM8Jncy2J9R/wEbGpD9tAy21Fdkdrkzjs8j4ELwPnOxRzfPFrJC7Aj9fqx+EdU1i/A FwLAdjdHO6EICAOBIAYKa8fGnWa6jsxISpztyHkXXvO5sK1an2uG2AHY+R3DGRV/jOC0yhXnNAkEQ XbwQRgPw==; Received: from mout.kundenserver.de ([212.227.17.10]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ldUqB-002wVn-EX; Mon, 03 May 2021 09:26:13 +0000 Received: from mail-wm1-f41.google.com ([209.85.128.41]) by mrelayeu.kundenserver.de (mreue108 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MVvGt-1m2UMl0DXp-00RtDF; Mon, 03 May 2021 11:26:06 +0200 Received: by mail-wm1-f41.google.com with SMTP id u5-20020a7bc0450000b02901480e40338bso3152620wmc.1; Mon, 03 May 2021 02:26:05 -0700 (PDT) X-Gm-Message-State: AOAM530BbjWCl/9wT5pUl+H7p54H5RnkSUhBZVgduGXwWJHu6xrL34PJ PPmVbTucfgWpmtehpU2Mxn9qq+1zJpHkQrjnx40= X-Google-Smtp-Source: ABdhPJyImR0lXDOWh/rFmKSSJQOuX4SzDcgMMWQ8OtmjXS6cOp8lf5wEACKwu1MdktyqNDYlMn4UdggeZ8LLn0fAS0M= X-Received: by 2002:a7b:c344:: with SMTP id l4mr30642981wmj.120.1620033965603; Mon, 03 May 2021 02:26:05 -0700 (PDT) MIME-Version: 1.0 References: <20210501151538.145449-1-masahiroy@kernel.org> <3943bc020f6227c8801907317fc113aa13ad4bad.camel@perches.com> <20210502183030.GF10366@gate.crashing.org> <81a926a3bdb70debe3ae2b13655ea8d249fb9991.camel@perches.com> <20210502203253.GH10366@gate.crashing.org> <20210502223007.GZ1847222@casper.infradead.org> In-Reply-To: From: Arnd Bergmann Date: Mon, 3 May 2021 11:25:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Raise the minimum GCC version to 5.2 To: Matthew Wilcox , Linus Torvalds , Segher Boessenkool , Joe Perches , Miguel Ojeda , Masahiro Yamada , Albert Ou , Arnd Bergmann , Linux Kbuild mailing list , Greg Kroah-Hartman , Jonathan Corbet , Linux Doc Mailing List , linux-kernel , Palmer Dabbelt , Paul Walmsley , Catalin Marinas , Miguel Ojeda , Paul Mackerras , linux-riscv , linuxppc-dev , Will Deacon , Linux ARM X-Provags-ID: V03:K1:dfF0glRwgJZb8sIdPte6x8c+oPsO7va6VRFuZtiqpEPqHpLWebf ITPeCDQkSqE4fke3nne040PqSBzm1QvXi8zvaRB6B4UO0DplEN95snpw9yKOlzm+eqdKc0w ItdktX1oWH+domOXvJR39lfPpSw5l+X593fxnEyRPpi46yqL5rAN0DqUUHEHRGCyVTOQDS3 S7zsuuzzFGW6OlKlQJhfA== X-UI-Out-Filterresults: notjunk:1;V03:K0:djw/hfV7cuQ=:oPg44G3dbPza8RnxAIMF05 ewrz9peMKs1f/CV7sLXFKf/gFmb9zHwiJctto60+Y8UKi86u6/QlDjPai7inWFrhmKynST8Fr qwy66OGURqVTyVqAHAwPPxy2GRCNio2ruEspjN1MSerAKhcTN60lb2dsv+D9eI+YZxpn3HZXE YEMKTTuPSv6IV6wlXR4ifecMt8fptICPJJmsi2aQUt7AQiaBjf6fA9aywruLEBYJD8Fn6vF15 h/YrrqaHnyLbfCY8qgZnKoUtFRiR3/CJqYUS7pKw+hoH9lzXe7CgFt6GPKLnfZTzM2A/2Nz8j jPI+/IGcLkXdckxz3r6NlS2LheiHt32Hw+hRfwCOrYuH0JBilAqWjmvzZoNiVZzVa8VCDR0ip nm0kM5vxa99ctBcMxqBlx9NPLnTi3hul/7cxxVwlcTvg7gePOEf3QMAXTEWtDfkyRwWdei96x iWn/qdnvOzXL22JHPNQKsR4CezjkcU+vN7S0QUafXBI8iAkshlBgpduldBHOfuZs942cOcLT4 2zTSO6D9giwp4+Z/4JWoY8= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210503_022611_799366_C6D49BF1 X-CRM114-Status: GOOD ( 20.94 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, May 3, 2021 at 9:35 AM Alexander Dahl wrote: > > Desktops and servers are all nice, however I just want to make you > aware, there are embedded users forced to stick to older cross > toolchains for different reasons as well, e.g. in industrial > environment. :-) > > This is no show stopper for us, I just wanted to let you be aware. Can you be more specific about what scenarios you are thinking of, what the motivations are for using an old compiler with a new kernel on embedded systems, and what you think a realistic maximum time would be between compiler updates? One scenario that I've seen previously is where user space and kernel are built together as a source based distribution (OE, buildroot, openwrt, ...), and the compiler is picked to match the original sources of the user space because that is best tested, but the same compiler then gets used to build the kernel as well because that is the default in the build environment. There are two problems I see with this logic: - Running the latest kernel to avoid security problems is of course a good idea, but if one runs that with ten year old user space that is never updated, the system is likely to end up just as insecure. Not all bugs are in the kernel. - The same logic that applies to ancient user space staying with an ancient compiler (it's better tested in this combination) also applies to the kernel: running the latest kernel on an old compiler is something that few people test, and tends to run into more bugs than using the compiler that other developers used to test that kernel. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4665EC433B4 for ; Mon, 3 May 2021 09:26:40 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7F04761186 for ; Mon, 3 May 2021 09:26:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F04761186 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FYczy0fr4z30BC for ; Mon, 3 May 2021 19:26:38 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=arndb.de (client-ip=217.72.192.75; helo=mout.kundenserver.de; envelope-from=arnd@arndb.de; receiver=) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FYczT0KXyz2xZF for ; Mon, 3 May 2021 19:26:12 +1000 (AEST) Received: from mail-wm1-f41.google.com ([209.85.128.41]) by mrelayeu.kundenserver.de (mreue107 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MI4cT-1lopMv3QvP-00F9wB for ; Mon, 03 May 2021 11:26:06 +0200 Received: by mail-wm1-f41.google.com with SMTP id o26-20020a1c4d1a0000b0290146e1feccdaso4609884wmh.0 for ; Mon, 03 May 2021 02:26:05 -0700 (PDT) X-Gm-Message-State: AOAM531YipsjNHNXGzOwNDTmHlhci/Zlhono7yd4PqfthocQ+QMwybAc qFHqrQXoY7tqqpOq8O7/js4qrIXFpMnQjma272s= X-Google-Smtp-Source: ABdhPJyImR0lXDOWh/rFmKSSJQOuX4SzDcgMMWQ8OtmjXS6cOp8lf5wEACKwu1MdktyqNDYlMn4UdggeZ8LLn0fAS0M= X-Received: by 2002:a7b:c344:: with SMTP id l4mr30642981wmj.120.1620033965603; Mon, 03 May 2021 02:26:05 -0700 (PDT) MIME-Version: 1.0 References: <20210501151538.145449-1-masahiroy@kernel.org> <3943bc020f6227c8801907317fc113aa13ad4bad.camel@perches.com> <20210502183030.GF10366@gate.crashing.org> <81a926a3bdb70debe3ae2b13655ea8d249fb9991.camel@perches.com> <20210502203253.GH10366@gate.crashing.org> <20210502223007.GZ1847222@casper.infradead.org> In-Reply-To: From: Arnd Bergmann Date: Mon, 3 May 2021 11:25:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Raise the minimum GCC version to 5.2 To: Matthew Wilcox , Linus Torvalds , Segher Boessenkool , Joe Perches , Miguel Ojeda , Masahiro Yamada , Albert Ou , Arnd Bergmann , Linux Kbuild mailing list , Greg Kroah-Hartman , Jonathan Corbet , Linux Doc Mailing List , linux-kernel , Palmer Dabbelt , Paul Walmsley , Catalin Marinas , Miguel Ojeda , Paul Mackerras , linux-riscv , linuxppc-dev , Will Deacon , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:Yt8y2oAEvHtZyOEZmHalfXHLhoY/ILWrhc1Almw/GsQZ1Ws8zJK fnqam3apDhj3xKlwpy6OyhfYxR0bVI7DD9xrb4Z2Yx6YcHed3krvTsHiQDiLUTlyvRXntxf QU8ORQdec8+2ngsZx8K7sJL0aio63+jLUSXa8NPKSCoNl5+UAW7+HLcAuClR51r8k5i9CPZ g5WgarmCzRotjLtFdJ+zQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:KhnPSLrTO8E=:EYxMAhVcTAdKnY6AZrLXjw YOZ2RwftwvJDNtqAiJE6Pp2OizZzMQOxcv4IvPHZDCUqwkFkNi1tsTZaGORU2hLQY7oJqKhq4 WSNMQPOoRI4dQLT1MvpCUUp5Gmu3+Qp/L71ctBGHpRxCcfihYXlfuiZfaChn5jWnaUjxFNCDd lUwdjrieU0cerEBCoMs9SQ2lMlgk7201uKg69c+jqOMd1V3UED7x/hEquVvqwj4jv+9mcH+xk hQ4SbQURL6Q5/lQClbEkfwXguvxMZ1V3PedyL4G9ZBCm1jomlLj7clqrw05kByXWR/X49Mp1l 6+fGvUhKcDk+uqiiv70eWpWRGuR3ejje8LpRYCSLtBe3kpBOMhgL4MzuttSC5ViScWfUvoUKW LSrK3WqoxximBnPM7RcbdAotXrfdvA9SbK9Ip4PvpKFyF7nmjBfFqsh9kjwP2fEQRf0fZfJ8+ lEf3m5bndTREUwUipzKo6sKVk9c+bxJ+RGIlGUQXcG1IP4jeOpn5lBPZ0F6U7a5z6/L47Jxyr 6za/qBrRusrjYM+F8xBN5Q= X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, May 3, 2021 at 9:35 AM Alexander Dahl wrote: > > Desktops and servers are all nice, however I just want to make you > aware, there are embedded users forced to stick to older cross > toolchains for different reasons as well, e.g. in industrial > environment. :-) > > This is no show stopper for us, I just wanted to let you be aware. Can you be more specific about what scenarios you are thinking of, what the motivations are for using an old compiler with a new kernel on embedded systems, and what you think a realistic maximum time would be between compiler updates? One scenario that I've seen previously is where user space and kernel are built together as a source based distribution (OE, buildroot, openwrt, ...), and the compiler is picked to match the original sources of the user space because that is best tested, but the same compiler then gets used to build the kernel as well because that is the default in the build environment. There are two problems I see with this logic: - Running the latest kernel to avoid security problems is of course a good idea, but if one runs that with ten year old user space that is never updated, the system is likely to end up just as insecure. Not all bugs are in the kernel. - The same logic that applies to ancient user space staying with an ancient compiler (it's better tested in this combination) also applies to the kernel: running the latest kernel on an old compiler is something that few people test, and tends to run into more bugs than using the compiler that other developers used to test that kernel. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38C02C433ED for ; Mon, 3 May 2021 09:28:24 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9A85C6127A for ; Mon, 3 May 2021 09:28:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A85C6127A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dmNspVZc+WttI9c3FGQc2MvWFVyiLKWy+DugtzJgOso=; b=OZllOoGBiHP9+1 Zzg5qsVhavtRAvzFGFKkK0Mq38Q1vE7yne9MSK4Az9i9bd1ozH9xHWIpidfh1ZGnO1wJPHSuk7rkp GH2leuXCfUuKyECl8A7b0MC6IiJOYg3v+LozzT+Y/bmgnqxJ9/YCpWYw/lBPBAQPYwoFPaU4ad+rH jij4SGYNxJUlnfOZ9hxBbuW0W5+jFBkgzdPlgbWASEEnoN4c8T4Tmw3mnCz2pb6rYZMlRhBch60xW v1neC7I0++Q2MhF3Q4Dmx36B846Br7s1e5PO+7Qz6ysZnn16XaQffmkw16fvW0YKO7HmozP2ycIWv hlFTgRJqBOz9+2NZSOKw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1ldUqP-00DX9u-EM; Mon, 03 May 2021 09:26:25 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ldUqE-00DX93-Ca; Mon, 03 May 2021 09:26:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:To:Subject:Message-ID: Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=fLy9DiO4d7hbeLXoGuF654ufloNHLfA8Z/WN8IvEIrw=; b=kE/KWJcXUMDiX/bLnTIIk8V3EZ RDQi4rzJ1j/t3S+F1r5KI6oW3iLmtpur+TSElahzOdrDxSqqZ+6hxmw9vW+UiXGyfT5vooXS9txxs YdXy/9aoUppEx4211oc/14RI8P1yNGsXiOluhKWCJXylihLWa2xo/SlSSZRR9+xTk6/+BlLlz1vsJ lBDnTc6hu9TUM8Jncy2J9R/wEbGpD9tAy21Fdkdrkzjs8j4ELwPnOxRzfPFrJC7Aj9fqx+EdU1i/A FwLAdjdHO6EICAOBIAYKa8fGnWa6jsxISpztyHkXXvO5sK1an2uG2AHY+R3DGRV/jOC0yhXnNAkEQ XbwQRgPw==; Received: from mout.kundenserver.de ([212.227.17.10]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1ldUqB-002wVn-EX; Mon, 03 May 2021 09:26:13 +0000 Received: from mail-wm1-f41.google.com ([209.85.128.41]) by mrelayeu.kundenserver.de (mreue108 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MVvGt-1m2UMl0DXp-00RtDF; Mon, 03 May 2021 11:26:06 +0200 Received: by mail-wm1-f41.google.com with SMTP id u5-20020a7bc0450000b02901480e40338bso3152620wmc.1; Mon, 03 May 2021 02:26:05 -0700 (PDT) X-Gm-Message-State: AOAM530BbjWCl/9wT5pUl+H7p54H5RnkSUhBZVgduGXwWJHu6xrL34PJ PPmVbTucfgWpmtehpU2Mxn9qq+1zJpHkQrjnx40= X-Google-Smtp-Source: ABdhPJyImR0lXDOWh/rFmKSSJQOuX4SzDcgMMWQ8OtmjXS6cOp8lf5wEACKwu1MdktyqNDYlMn4UdggeZ8LLn0fAS0M= X-Received: by 2002:a7b:c344:: with SMTP id l4mr30642981wmj.120.1620033965603; Mon, 03 May 2021 02:26:05 -0700 (PDT) MIME-Version: 1.0 References: <20210501151538.145449-1-masahiroy@kernel.org> <3943bc020f6227c8801907317fc113aa13ad4bad.camel@perches.com> <20210502183030.GF10366@gate.crashing.org> <81a926a3bdb70debe3ae2b13655ea8d249fb9991.camel@perches.com> <20210502203253.GH10366@gate.crashing.org> <20210502223007.GZ1847222@casper.infradead.org> In-Reply-To: From: Arnd Bergmann Date: Mon, 3 May 2021 11:25:21 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Raise the minimum GCC version to 5.2 To: Matthew Wilcox , Linus Torvalds , Segher Boessenkool , Joe Perches , Miguel Ojeda , Masahiro Yamada , Albert Ou , Arnd Bergmann , Linux Kbuild mailing list , Greg Kroah-Hartman , Jonathan Corbet , Linux Doc Mailing List , linux-kernel , Palmer Dabbelt , Paul Walmsley , Catalin Marinas , Miguel Ojeda , Paul Mackerras , linux-riscv , linuxppc-dev , Will Deacon , Linux ARM X-Provags-ID: V03:K1:dfF0glRwgJZb8sIdPte6x8c+oPsO7va6VRFuZtiqpEPqHpLWebf ITPeCDQkSqE4fke3nne040PqSBzm1QvXi8zvaRB6B4UO0DplEN95snpw9yKOlzm+eqdKc0w ItdktX1oWH+domOXvJR39lfPpSw5l+X593fxnEyRPpi46yqL5rAN0DqUUHEHRGCyVTOQDS3 S7zsuuzzFGW6OlKlQJhfA== X-UI-Out-Filterresults: notjunk:1;V03:K0:djw/hfV7cuQ=:oPg44G3dbPza8RnxAIMF05 ewrz9peMKs1f/CV7sLXFKf/gFmb9zHwiJctto60+Y8UKi86u6/QlDjPai7inWFrhmKynST8Fr qwy66OGURqVTyVqAHAwPPxy2GRCNio2ruEspjN1MSerAKhcTN60lb2dsv+D9eI+YZxpn3HZXE YEMKTTuPSv6IV6wlXR4ifecMt8fptICPJJmsi2aQUt7AQiaBjf6fA9aywruLEBYJD8Fn6vF15 h/YrrqaHnyLbfCY8qgZnKoUtFRiR3/CJqYUS7pKw+hoH9lzXe7CgFt6GPKLnfZTzM2A/2Nz8j jPI+/IGcLkXdckxz3r6NlS2LheiHt32Hw+hRfwCOrYuH0JBilAqWjmvzZoNiVZzVa8VCDR0ip nm0kM5vxa99ctBcMxqBlx9NPLnTi3hul/7cxxVwlcTvg7gePOEf3QMAXTEWtDfkyRwWdei96x iWn/qdnvOzXL22JHPNQKsR4CezjkcU+vN7S0QUafXBI8iAkshlBgpduldBHOfuZs942cOcLT4 2zTSO6D9giwp4+Z/4JWoY8= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210503_022611_799366_C6D49BF1 X-CRM114-Status: GOOD ( 20.94 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 3, 2021 at 9:35 AM Alexander Dahl wrote: > > Desktops and servers are all nice, however I just want to make you > aware, there are embedded users forced to stick to older cross > toolchains for different reasons as well, e.g. in industrial > environment. :-) > > This is no show stopper for us, I just wanted to let you be aware. Can you be more specific about what scenarios you are thinking of, what the motivations are for using an old compiler with a new kernel on embedded systems, and what you think a realistic maximum time would be between compiler updates? One scenario that I've seen previously is where user space and kernel are built together as a source based distribution (OE, buildroot, openwrt, ...), and the compiler is picked to match the original sources of the user space because that is best tested, but the same compiler then gets used to build the kernel as well because that is the default in the build environment. There are two problems I see with this logic: - Running the latest kernel to avoid security problems is of course a good idea, but if one runs that with ten year old user space that is never updated, the system is likely to end up just as insecure. Not all bugs are in the kernel. - The same logic that applies to ancient user space staying with an ancient compiler (it's better tested in this combination) also applies to the kernel: running the latest kernel on an old compiler is something that few people test, and tends to run into more bugs than using the compiler that other developers used to test that kernel. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel