Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3725156yba; Tue, 9 Apr 2019 03:32:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqwKB1MaDDPqEq7K3we/H+sdI3l57el4L+uICsGAFsAszpeRrWfT2/uO0+OLoHXQt+oVEFqT X-Received: by 2002:a65:6389:: with SMTP id h9mr34100439pgv.398.1554805958992; Tue, 09 Apr 2019 03:32:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554805958; cv=none; d=google.com; s=arc-20160816; b=D3zVRqGkh9pqL5J7ZgWjGe/QkRmhSKA+qmEl2V5fix/P+Cvuiojl9odqv6IIJGRN0G iQB/hOMXnl8BFumwsRRaZ7DRU0MUYFMyaweMYjwqRiZicpJvi6JrRV9FLwHW6E6QZIkQ 19rZ2tfdx5qWwzuJnQh9TpE6hUzIbLi53MHZj0hexTslDREPJakVNLOQAtGAI15XgQYu UwjmJ5cRg+ZH9YkaK2QBtlkHfljw0YTSUCHjniKrlTHZ+fPRA3Vt5skJcjRxndht1bWp Fu2K1fhDF5xBfEjvO44kAqkhQdz0v9TPZvq0LycbCcH7N5zbYHYBbT8dI5FcnuehDrV6 sxnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=eQx2TaUwh8Ijip8QcXaY6f2a/ThB22gwO6hBQo1xRKk=; b=NK0hf0f7cI/70TKmRKBhY2QiTZ4fc7gyWeTAwv5du7W+x+vx5wpN/urRsXnMi+uJXw UaWVknEV2HZXiM/lhzGQJc/XgdRkp3q7zs0kggR8N1t0T1a9qIIOWi7NH2423xuEdILk +ZLtFYjOF7t+/yhiVDRI2i/vjLdoXllV5VcGNoOIz+cuUu1ZipV5Fz7jCG7+xQ17+mLU t32iyValhQ/Rrs7NQ7++odJkbYxyLN/kAs/fsPTPXgr3DL8IaILfhEBPpol7G7AnIF1r XUboJVU3lzi78Ea92TJ/PPQA43bDKHUIWEX5iFwBGNfcQezpJN+1wsruS9nbN75Lqp3P /yPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YL5cHOV7; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j187si11954240pfc.181.2019.04.09.03.32.23; Tue, 09 Apr 2019 03:32:38 -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=@gmail.com header.s=20161025 header.b=YL5cHOV7; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727073AbfDIKb0 (ORCPT + 99 others); Tue, 9 Apr 2019 06:31:26 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:37597 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726112AbfDIKb0 (ORCPT ); Tue, 9 Apr 2019 06:31:26 -0400 Received: by mail-wm1-f67.google.com with SMTP id v14so2698586wmf.2; Tue, 09 Apr 2019 03:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eQx2TaUwh8Ijip8QcXaY6f2a/ThB22gwO6hBQo1xRKk=; b=YL5cHOV71rwriAeEampk6JbeFmiSG0j85iHAvhFZNXiX9OQVvsvUamCtBYywWM2eIi oDs/1zdU1WXmI7gDpNMGLdrdCvyTsMQjTz0IS7uftjXst7+BEKzRqQHwLZKqs33GMylI s6RUJLYQsPiDhiAc0unP0lXR7It93WaLCpndtJpOGQbF+0XCbmx+jqB/TPc2IVzq+rXj FSJlhladz5v1HtjhkpSR1MyQiFUdAVFihOeYQdcmrlwQ8SZ8AU/TbloiEceD9m0pCCAQ rc0hC4kQMCVMKUKS3P/WmjBFlm/F3FCklNJfngDoTZ4IP4XAt4nBlbQU06Fir4pDMlwW aqEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=eQx2TaUwh8Ijip8QcXaY6f2a/ThB22gwO6hBQo1xRKk=; b=SQe/6skTJbT2u1GwLlRHzL8rgKmnz114VCqFKxYIMbALZ1gyBFn4FGhHmJeaVgvzgz sQhsc050MA6azbjiI6YKPRKuRdk6ndvc5dMwosJnq5n4nm+OghxRRWB+hDWwoxijVlhl zLoza5JNKykClfjKCnmGMtZXMZLkWNfr32avaoM4vQPj1efHcrw7bcuaoKh2d+z7k5mj 8CMLwDhE4mO48Dxxk8mrYu06Rw4VpoJ62c2kTVD4ivM84lXRRdn2X3GX/aybqmes7hgL 0pf0ZIOmXE0F4+DWMudE2QmBdWLMkDLN44iEzbpfCFRJjmWO+M24YlkBHCnmZNNt6dcP SwZA== X-Gm-Message-State: APjAAAXAPgSdfejBQTjwLP6twvy+vqZ6r/hTgzXu5tFz9U7P3SeK5We5 nFo/fA4RBLdyr+zsjPv7BRpa3TfDXhdwtiWne8E= X-Received: by 2002:a1c:1f08:: with SMTP id f8mr19380750wmf.97.1554805884278; Tue, 09 Apr 2019 03:31:24 -0700 (PDT) MIME-Version: 1.0 References: <77e11884-f520-d983-3d33-ccc3043ba604@nokia.com> In-Reply-To: From: Jonas Gorski Date: Tue, 9 Apr 2019 12:31:15 +0200 Message-ID: Subject: Re: [PATCH] modpost: make KBUILD_MODPOST_WARN also configurable for external modules To: Masahiro Yamada Cc: "Wiebe, Wladislav (Nokia - DE/Ulm)" , "michal.lkml@markovi.net" , "linux-kbuild@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, =E6=9C=AC=E5=BD=93=E3=81=AB=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=82=E3=82=8A=E3= =81=BE=E3=81=9B=E3=82=93, I got sidetracked and completely forgot about it.= I actually still have my old tree with the suggested changes for v2. On Tue, 9 Apr 2019 at 11:01, Masahiro Yamada wrote: > > 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 configura= ble. > > >> Right now KBUILD_MODPOST_WARN gets just ignored when KBUILD_EXTMOD i= s > > >> set which happens per default when building modules out of the tree. > > >> > > >> This change gives the opportunity to define module build behaving al= so > > >> 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 t= he 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_SY= MBOLS, > or KBUILD_EXTRA_SYMBOLS=3D1 to turn the error into a warning. This sounds like a good middle ground. When you do the effort of setting KBUILD_EXTRA_SYMBOLS, you are likely interested in proper dependency resolution and being notified if it fails. I would probably still use KBUILD_MODPOST_WARN=3D0 to force the warnings as errors, to have it as the central switch for the behaviour. So the behaviour would then become - If KBUILD_MODPOST_WARN is set to any value, set -w accordingly - else, set -w only when building for an external module and KBUILD_EXTRA_SYMBOLS is empty or ifdef KBUILD_MODPOST_WARN KBUILD_MODPOST_WARN:=3D$(filter-out 0,$(KBUILD_MODPOST_WARN)) else KBUILD_MODPOST_WARN:=3D$(if $(KBUILD_EXTMOD),$(if $(KBUILD_EXTRA_SYMBOL= S),,1)) endif (completely untested) Regards Jonas