Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp818042rwl; Fri, 24 Mar 2023 02:20:40 -0700 (PDT) X-Google-Smtp-Source: AKy350ZXEtT5CWGqe+pvP6cZEI7DnapTifkmQ7KdD51aJkflEWrYjibgkJ+43BAt+Ld0QIkU1Lol X-Received: by 2002:a17:906:7e4a:b0:93d:f7a6:219b with SMTP id z10-20020a1709067e4a00b0093df7a6219bmr1639359ejr.65.1679649640233; Fri, 24 Mar 2023 02:20:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679649640; cv=none; d=google.com; s=arc-20160816; b=Dc/TZ26W1fcs9YqzOmkef0AxS93W1MF5JWHuXfeKN+kxd9FeaKHELmKATB6wuFtgC6 GmEIMRBECT7EOqdKXs8FDga1uM4LCEKxMunTYpjQzquKZGMLoavoU5IaPhojPQPVGdtl 9uHe6lJ640fV/dL3ugCRE9j5YUhBIQpqZWX3umXltUrqJXdG8QGaj8+QQSju09purv5H cFgrQZ9P79+HMK09+UFQ0YpNhUzdkJLK2inC08dBOF8R5ws5q2E9QHUJAzyDlv+9n3bq /ccXZSUqYPyJ40wjPahY9/IYjw8bYvTeiYY3uSTyLGVgf2q1POkT3ltOrve1qU/UnRKi 08BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=YYnqlMjvviIvGO4XhcSWDH4Tu/u7EEhNnZWgpmRC0OY=; b=gEu5WoB/XF2K8Jn/0GbuWyUy/A18nZPMzwNw+cJ5LWw88T+LYcljqxwjUp2u7cjvQc 2OEyRf+YOccqEHJSFmWhz57DrvQg8T1fuFmvfd1kjIUK4y54ONRCzjsGIRmXaZOt21zk 0zml4mM9dd0QNGdATsU7jERxH8PUHufpXuyQ6PHXRwuJc+Xy+lyP+Ar/PxJ4sWbou7lv Cw2emuK4ZZo/8GnoNr6erQpoAKg8h1Yb9r6LauXYeYvNeZNHlaBaNv4WLEVU7rql5Z4g 97GNQZlvWYOKdCcVLreWuNOOv3vntjCMFag8UpD283N2OruDwiX6M/ugN2vcdcH7uu+E AbAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=d1wYyxBm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sc6-20020a1709078a0600b0093cd63ce6f8si4787274ejc.523.2023.03.24.02.20.16; Fri, 24 Mar 2023 02:20:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=d1wYyxBm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231626AbjCXJO0 (ORCPT + 99 others); Fri, 24 Mar 2023 05:14:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229997AbjCXJOX (ORCPT ); Fri, 24 Mar 2023 05:14:23 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA834212A5; Fri, 24 Mar 2023 02:14:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 53781B82316; Fri, 24 Mar 2023 09:14:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DDCEC433D2; Fri, 24 Mar 2023 09:14:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1679649258; bh=WCARbpiOxTXO6BSITyeU7LBK8Ia30GL8OgERpWRb294=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d1wYyxBmFwqHj5JKS5mx9C0QS/hQJBQcg2Zj202xg9u5gVb1A03KlPH3WC7i1QgXX Lrh2aQNsrNmFwYyiHuBO/ARcN7/9nKjGjBVBpgJSvxZqrVoihuM4SCYhyxQpNv3qvy /R2KCJrnps5ZkSX5GabmhkzHE9z1eexBu1ugM3gw= Date: Fri, 24 Mar 2023 10:14:15 +0100 From: Greg Kroah-Hartman To: Geert Uytterhoeven Cc: Luis Chamberlain , Masahiro Yamada , Thomas Gleixner , Christoph Hellwig , Nick Alcock , linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org, Hitomi Hasegawa , Jiri Slaby Subject: Re: [PATCH 10/17] tty: remove MODULE_LICENSE in non-modules Message-ID: References: <20230302211759.30135-1-nick.alcock@oracle.com> <20230302211759.30135-11-nick.alcock@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-5.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 24, 2023 at 10:08:17AM +0100, Geert Uytterhoeven wrote: > On Fri, Mar 10, 2023 at 8:42 PM Luis Chamberlain wrote: > > On Fri, Mar 10, 2023 at 08:31:30AM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Mar 09, 2023 at 02:38:10PM -0800, Luis Chamberlain wrote: > > > > On Thu, Mar 09, 2023 at 05:15:42PM +0100, Greg Kroah-Hartman wrote: > > > > > On Thu, Mar 02, 2023 at 09:17:52PM +0000, Nick Alcock wrote: > > > > > > Since commit 8b41fc4454e ("kbuild: create modules.builtin without > > > > > > Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations > > > > > > are used to identify modules. As a consequence, uses of the macro > > > > > > in non-modules will cause modprobe to misidentify their containing > > > > > > object file as a module when it is not (false positives), and modprobe > > > > > > might succeed rather than failing with a suitable error message. > > > > > > > > > > > > So remove it in the files in this commit, none of which can be built as > > > > > > modules. > > > > > > > > > > > > Signed-off-by: Nick Alcock > > > > > > Suggested-by: Luis Chamberlain > > > > > > Cc: Luis Chamberlain > > > > > > Cc: linux-modules@vger.kernel.org > > > > > > Cc: linux-kernel@vger.kernel.org > > > > > > Cc: Hitomi Hasegawa > > > > > > Cc: Greg Kroah-Hartman > > > > > > Cc: Jiri Slaby > > > > > > --- > > > > > > drivers/tty/n_null.c | 1 - > > > > > > 1 file changed, 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/tty/n_null.c b/drivers/tty/n_null.c > > > > > > index f913b665af725..c24f75942c49d 100644 > > > > > > --- a/drivers/tty/n_null.c > > > > > > +++ b/drivers/tty/n_null.c > > > > > > @@ -63,7 +63,6 @@ static void __exit n_null_exit(void) > > > > > > module_init(n_null_init); > > > > > > module_exit(n_null_exit); > > > > > > > > > > > > -MODULE_LICENSE("GPL"); > > > > > > MODULE_AUTHOR("Alan Cox"); > > > > > > MODULE_ALIAS_LDISC(N_NULL); > > > > > > MODULE_DESCRIPTION("Null ldisc driver"); > > > > > > -- > > > > > > 2.39.1.268.g9de2f9a303 > > > > > > > > > > > > > > > > Nope, sorry, this is not good to do, please fix kbuild instead of > > > > > forcing a tree-wide change like this. > > > > > > > > Masahiro Yamada already NACK'd it such effort: > > > > > > > > https://lkml.kernel.org/r/CAK7LNAQLttPD=Ae==e0CYeQtS78=o_JZFK+zxa29JnUYio52Ug@mail.gmail.com > > > > > > > > And his descriptiuon of the reasoning and logic is explained here: > > > > > > > > https://lore.kernel.org/all/CAK7LNASL7_RgfASstBvN6AzhR=nMU=HsQvODf5q13Xud8tBWRQ@mail.gmail.com/ > > > > > > > > Let me summarize it though with a few quotes from him: > > > > > > > > "Having false-positives in modules.builtin should be OK" > > > > "In this sense, having always-builtin entries in module.builtin is OK." > > > > > > None of that matters, sorry. > > > > > > Again, all I am saying is that you can not have some MODULE_() macros > > > that are ok for code that is built in, and some that are not, for > > > "reasons" that have to do how you all are treating the build system > > > infrastructure as you are now putting arbritrary requirements for all > > > driver authors (of which there are thousands) to know this. > > > > As noted once again, it is not putting hard requirement. Future tooling > > not yet added would just not benefit from distinguishing symbols for > > your modules. > > > > I'm happy to live with module authors not wanting to remove the module > > license tag from their modules if they can never actually be modules > > from not benefitting from the above tooling gains as its just cherry > > on top tooling gains. > > Apparently lots of these patches have not arrived in linux-next > without Acks (we're still discussing about this, right???). > > And some of the modified files have no SPDX-License-Identifier > lines yet, so we are losing important licensing information: > > $ git grep -L SPDX-License-Identifier -- $(git show $(git log > --oneline v6.3-rc1..linux-next/master | grep "remove MODULE_LICENSE in > non-modules" | cut -d " " -f 1) | lsdiff --strip=1) > drivers/bus/arm-cci.c > drivers/bus/imx-weim.c > drivers/bus/simple-pm-bus.c > drivers/gpu/drm/drm_mipi_dsi.c > drivers/irqchip/irq-mvebu-pic.c > drivers/reset/reset-axs10x.c > drivers/reset/reset-hsdk.c > drivers/soc/sunxi/sunxi_sram.c > drivers/video/fbdev/asiliantfb.c > drivers/video/fbdev/gbefb.c > drivers/video/fbdev/imsttfb.c > drivers/xen/xenbus/xenbus_probe.c > lib/glob.c Ick, that's not ok at all. Again, I strongly feel that removing MODULE_LICENSE() lines from files that just don't happen to be built as a module is not ok as no other MODULE_*() macro has this arbitrary restriction. thanks, greg k-h