Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3664067yba; Tue, 9 Apr 2019 02:03:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqwoVZd4CnrWjiRO0DT8DJhlAN+IooOzP7oBv4rpJ9DTeHLsZw67ZFzCFQYdQT60MwDU8SaZ X-Received: by 2002:a17:902:6b03:: with SMTP id o3mr35860768plk.226.1554800592732; Tue, 09 Apr 2019 02:03:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554800592; cv=none; d=google.com; s=arc-20160816; b=tPK70QIe4Y8gDIZa6qut/zrXUcQ8bAeXMhu2xA8mEG9LB6osaMIgXBliyxZHJETDTo tJs2jaslwdDfBex7VNHBvWTsFZYp2NaAMKEd23tcjHUenIUFqknnp+kltbsZNsjNrT8a IMEY+375pthuDYML64xb9bYyJ5hqw2JFgrP8wJK5LbGoqVyUcouo+i6zmTgBxT51aD3W gUEdJS29Sd5A1fRGctqNnkEkxZ83hrZsVPqfOIWCfwonUfq1pqOgCNSb9S72hHotjOyS c/8XwlCskh6ogL7UA19oUEcRMAPe2vjHPajhlKIAQgauxzFfoDviW1HTCAiyKQPaBp3p TPmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature:dkim-filter; bh=uV840hlMmCm9z7nqOQ6xn6UBInSMmOukyeFySz6vLlc=; b=wfH/WBnd5rZjZGDr5DOHrnwzjU3pSaR5usUR56uz0uPnASw3t6rTTusI/Yw6YQveJv 1/HG74lfcNBl0K/58as5O4a6yfl5t38jNdn43zHV0UK311NuBMz6UFpEBX7QDMi280sm nx/IZlO7hKuuBljeApQzppfaNYOi8B/Cz5rVzS51qh60DZKmUgqp+awG0Mc6QZ9aaN7E ONpXM1QAs+yTwSkU9/DkUBb+L+X3kpvs1r6m9Lp07tyH59r5EU29toEASwx5tzmre72W Prf4s4CkzMJgNo9qLmVPZj89LESGrqC0qDmai1rW7yi7QuQKrhLT83AnknfMTHfnHODZ wKLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=uZTWWqFd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a64si29389670pge.592.2019.04.09.02.02.56; Tue, 09 Apr 2019 02:03:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=uZTWWqFd; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726686AbfDIJBR (ORCPT + 99 others); Tue, 9 Apr 2019 05:01:17 -0400 Received: from conssluserg-06.nifty.com ([210.131.2.91]:54727 "EHLO conssluserg-06.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726624AbfDIJBQ (ORCPT ); Tue, 9 Apr 2019 05:01:16 -0400 Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (authenticated) by conssluserg-06.nifty.com with ESMTP id x3991932009527; Tue, 9 Apr 2019 18:01:10 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com x3991932009527 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1554800470; bh=uV840hlMmCm9z7nqOQ6xn6UBInSMmOukyeFySz6vLlc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=uZTWWqFdTmu1yYi3/dUDNM+ZXcSHLpnjPZ15sU1kf6Yfbxwqn9cbH+Ga6IOsleG6K CTttg/Tp4romPKCnyiCrBXhuLwg/nUiJVAUtIi8zoLWdiYNqW9q9ipSpimHGhI9yHs XvhLstBQOGbp0VMNNk1tnTMr9XnCgFU9mie0FMcjE2B4q6pkUHYOo+8vL1RZgfktus tYtfsTnZHnxi9TPuuJrSf6cqajFbQEXCq18OIk9AS419kXOGYV8uV7YeZEcU4IYHMk iHh2XeaTfrjSjqKg3HrnBASdeGGXHMS0qFE+LOLwGSvdnVNrlEGeWMaCrGbDm5xctY yR8zmZzm3C5pw== X-Nifty-SrcIP: [209.85.221.182] Received: by mail-vk1-f182.google.com with SMTP id s63so3686323vkg.10; Tue, 09 Apr 2019 02:01:10 -0700 (PDT) X-Gm-Message-State: APjAAAWooRMJDJX2WpMelr/QrQpdikiHyfNJQF8vtKc4xJRfRREEskbo UvnTZf/Qa+v6AHfZprhv+dcUMSHfTl3XNroi+9w= X-Received: by 2002:a1f:1594:: with SMTP id 142mr18714478vkv.42.1554800469250; Tue, 09 Apr 2019 02:01:09 -0700 (PDT) MIME-Version: 1.0 References: <77e11884-f520-d983-3d33-ccc3043ba604@nokia.com> In-Reply-To: <77e11884-f520-d983-3d33-ccc3043ba604@nokia.com> From: Masahiro Yamada Date: Tue, 9 Apr 2019 18:00:33 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] modpost: make KBUILD_MODPOST_WARN also configurable for external modules To: "Wiebe, Wladislav (Nokia - DE/Ulm)" Cc: "michal.lkml@markovi.net" , "linux-kbuild@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Jonas Gorski Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi. On Mon, Apr 8, 2019 at 5:03 PM Wiebe, Wladislav (Nokia - DE/Ulm) wrote: > > Hi! > > On 07.04.2019 11:04, Masahiro Yamada wrote: > > (+CC Jonas Gorski) > > > > > > On Tue, Mar 26, 2019 at 6:58 PM Wiebe, Wladislav (Nokia - DE/Ulm) > > wrote: > >> > >> Commit ea837f1c0503 ("kbuild: make modpost processing configurable") > >> was intended to give KBUILD_MODPOST_WARN flexibility to be configurable. > >> Right now KBUILD_MODPOST_WARN gets just ignored when KBUILD_EXTMOD is > >> set which happens per default when building modules out of the tree. > >> > >> This change gives the opportunity to define module build behaving also > >> in case of out of tree builds and default will become exit on error. > >> Errors which can be detected by the build should be trapped out of the box > >> there, unless somebody wants to notice broken stuff later at runtime. > > > > If an external module refers to a symbol > > provided by another external module, > > this patch will turn the warning into the error by default, > > which is probably a bad idea. > > Indeed, exactly this should happen. You should fix your external module > dependencies by providing their symbols. Please use e.g. > KBUILD_EXTRA_SYMBOLS instead of converting errors to warning and hoping > that things will work. I know this option. What I want to say is, this patch changes the behavior, and may annoy some people. > Or how do you want to make sure module A still > delivers all symbols needed by module B after an update/changes? > Manually comparing the logs after an update or waiting until it turns > out broken during run-time? I wouldn't say this is a good idea :-) OK, so the commit log should record both the behavior change and workarounds. - If an external module being built refers to symbols in another external module, Kbuild previously showed a warning, but going forward it will turn it into an error. - To work around this, you should pass a symbol table via KBUILD_EXTRA_SYMBOLS, or KBUILD_EXTRA_SYMBOLS=1 to turn the error into a warning. Thanks. > > > I suggested a desired change in the following. > > https://patchwork.kernel.org/patch/9980691/ > > > > I am poking Jonas Gorski > > if he plans to send v2. > > I wouldn't vote for v2 based on explanation above. > > - Wladislav > > > > > > >> Signed-off-by: Wladislav Wiebe > >> --- > >> scripts/Makefile.modpost | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost > >> index 6b7f354f189a..fec6ec2ffa47 100644 > >> --- a/scripts/Makefile.modpost > >> +++ b/scripts/Makefile.modpost > >> @@ -78,7 +78,7 @@ modpost = scripts/mod/modpost \ > >> $(if $(KBUILD_EXTRA_SYMBOLS), $(patsubst %, -e %,$(KBUILD_EXTRA_SYMBOLS))) \ > >> $(if $(KBUILD_EXTMOD),-o $(modulesymfile)) \ > >> $(if $(CONFIG_SECTION_MISMATCH_WARN_ONLY),,-E) \ > >> - $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w) > >> + $(if $(KBUILD_MODPOST_WARN),-w) > >> > >> MODPOST_OPT=$(subst -i,-n,$(filter -i,$(MAKEFLAGS))) > >> > >> -- > >> 2.19.2 > > > > > > -- Best Regards Masahiro Yamada