From:   Nick Alcock <nick.alcock@oracle.com>
To:     Bjorn Helgaas <helgaas@kernel.org>
Cc:     mcgrof@kernel.org, linux-modules@vger.kernel.org,
        linux-kernel@vger.kernel.org, Rob Herring <robh@kernel.org>,
        linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/8] kbuild, PCI: generic,versatile: comment out
 MODULE_LICENSE in non-modules
References: <20230213225723.GA2941414@bhelgaas>
Emacs:  because editing your files should be a traumatic experience.
Date:   Tue, 14 Feb 2023 15:41:32 +0000
In-Reply-To: <20230213225723.GA2941414@bhelgaas> (Bjorn Helgaas's message of
        "Mon, 13 Feb 2023 16:57:23 -0600")
Message-ID: <873578xnir.fsf@esperi.org.uk>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1.91 (gnu/linux)
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?cHd6NpVbpnTKHJg7jAS+Ju2J99ImXni1E88mwkI1oOiybcMNZz/bVCQEOuFs?=
 =?us-ascii?Q?Hq4gesHI0SG4CuZ1zNf8941hnPzx1mdnRWGHvtMzWhWOhL8flgmbg/GGnjoM?=
 =?us-ascii?Q?tvLYvIEUF7Ym8k+aPf5ugmqD3MnI+k62bBnmmB79blGEXvPzXHdaZ2ZYIoOA?=
 =?us-ascii?Q?HkrSrSCshZmc0GA/UsXjncsrl1khSd26ZmTGzvxze8CIHIZJIs7Cyiwwb/cz?=
 =?us-ascii?Q?/b7CYesiW5RqcLvARRkm1NpMgkQ2LpKkGyUMWU9aLcOdqfjne+VoBHopxIz4?=
 =?us-ascii?Q?kVSo2lpvMuCDUoVL8t2uupKUYztGLyJ/H4+VrZoYEJK6G5iJChcH8xgU6IRK?=
 =?us-ascii?Q?8XvOCygmQKCQXsI0WVh4tTo/wi1DF1uEdXONYhCsfyr5lTnwMB1joAz2ogJj?=
 =?us-ascii?Q?2RaeBS6ue3Hm8hlwKHJVlM9gs9Grm/1VY9MN6ncYexWQtM2yOoEzEoTd94u3?=
 =?us-ascii?Q?rv8X0ocuYwgus3rX67pFsHzoZeIWcZnWyyn2SJ52yJsGYzZIIEIYIlMXW8nU?=
 =?us-ascii?Q?45lhHgxYTgY/mkF7++RKxQN+roeKTVfG3scJk37OMFBsaiv72cDh3fyjSebY?=
 =?us-ascii?Q?KbNBwnb8v4EkqFZ/5QnCBC9xAoosVX6ZNZv027BkAeE0zGohbEGn07xoEqdJ?=
 =?us-ascii?Q?iqK5T7POmXS2DcHjiIlRyyXg2WfAYfPYir9MrqKJVk6amhrcWi9rj9Kmz+GG?=
 =?us-ascii?Q?Y9ikOQr3kmUctuIMmj+jWwCiOhwBKsXzphwEpyw7YR0CZjqROsOZCMYo8nJ1?=
 =?us-ascii?Q?36hMzD/XfNkVF85gi0qCcKTgmbk8911pYUZfy1/+VmYAXDf/Eb1WsUNC0nbs?=
 =?us-ascii?Q?cqNwWYaBfutS7YawY3KQARKHrkMULq099nKrmUmL2NdfHtgmwCPG8N+6vDG+?=
 =?us-ascii?Q?T0TzSJgbuN1vtvtW9cRnJme1FuwlCiGETsdV+S9rdVRyNDgM1jVtyYoP0qXf?=
 =?us-ascii?Q?itFILkJFCOhdsqMaysq9i/dCz2PDTW/RYtCcixkCghK7deLl/XWeJDNKzNxm?=
 =?us-ascii?Q?Ab80tznPxwg4L1mCKNr5RZt00OLm885OGkdpv4N7fXa3NPUDVAMc4TZJTq8e?=
 =?us-ascii?Q?luDq6UlHlgPNPRG6znl8a1+qW+wG7bP5g6m/Anpc3XQ/1Pos6arjSAKsomj1?=
 =?us-ascii?Q?/JUJBJbpj9MrNxcu+AVtY19spqkGjUNyjv/ajI012qU9gxVjAH+cWJRW7Ywx?=
 =?us-ascii?Q?npO+nkCdVi83JjFeHqrQER6DpFhvyM+XFRep4UhS3LYSOMEWLhY+qb4bd9Ed?=
 =?us-ascii?Q?v4jG6nTYTtfzFEaQ34dBvEqAdaWyIagxBE4Yx++qHdnkTlF7qMuB5866d2+A?=
 =?us-ascii?Q?eKho4NtC1vci39ehQBMnoFLFXLPHT/D0CKpb00o3C8AnsvAmO7FdT1n4+0GQ?=
 =?us-ascii?Q?kre1Wu0X7xGXZtY/+7KNsHOu8Em9A6k3ROjxqr9rG1kLIWQQgu+cq8NoxI59?=
 =?us-ascii?Q?3q7T2AGhWWSaGD/iBmiL9jLSNKjH+8mm3Oq6/TowyX3TmnhEjgUSMbM5cgsI?=
 =?us-ascii?Q?35Cxd8VR5nB7MaZW8Mo4dpgu/PT1s7cgKPmxOchzXs7mbqMrVa9adS4zoGDb?=
 =?us-ascii?Q?eLgob7rmhW/mOP/0qtKh7vfJrmfSddfNqKL6zdwoXzrG1iuoPXyHNCgoHL+g?=
 =?us-ascii?Q?/Q=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: kOlVrknEZnlMQGo/SVly3Z81VaaUOJeZYKezl2+KBZc5QvzUBj4S2PV1/ARbrk0aVsGwNwJto8VMsWKD/NZGNDWL+P8Hj6Sy1G/nwxGXLM2NTKjkuDtfZo3t5bLmZ7V1qBNRKtbiN6HVlEvbXyWWQB69tLxh/Eo9/UhfVLUkPIjZmjxDPIuioguVzWbXRVuXXA3FuCuL5E+6lBz9nWVdZLrT69bgl4H53K43FVR3m9syguCbnTfIv0pIW5KTe5toSav9mCzqNjWNZdVYJewkq1nuFtFC4B6BpLTqdkyhHo1+sD9bUsuoV2U8fHNgWOfakIra5Ra+ytnVF84tGI4+Mi418T8/KZjWtk1S8TSHHneCez8s7WM+QxCvCvcesyjaxdxQ+6LPTig4DI+DnTkPg3W+JkJ7a7JqCGN3EiDgK8FlqXhnmmRv4MhnKZAOgXGPf6crKZCuiroFho0H4x94/m+lljtE/U/1/YpScyGOkLTEchjvv2PwfUwQI9SKRKIwoY2ecHhj1f1pNA5Avj55MIhQKGacvoDkbrq+oaK9J1EnyCYqu2rQeesjX4dgZ3IzoXQ53mTps2bK2gf2XOlBHmuZaWOnJ0JvdNxJseg2gqOs4FtNWH/TqLNTf+eiOv5oy0gDdM1p0yCuq72C3h9W8K5Lf13CQXz7YcGtXWF7fIdIco0NvRzQDiPLxWfjQAaXXttq8PlP9eKwaiqsJQM1yIE6twLJdOkElnNTllU0qXpS2mwOGOMYij48fXyCaIAeI172kttG6gYv4xLWdThPdEPq14u1QjaTD1eJbxNskHfx7Zl8G2aL5zVBLgxxnb6wpWvbZMsVun8pHJW500fKuA==
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bc80364b-2ab8-4475-b640-08db0ea1f64d
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB6798.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2023 15:41:39.0525
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: zly4UUVF5Tn8pW9ZhaH3uw/wwGTcTlL45pa/qYhhIxUxf9tQkfzui6aOjzGZVIq8Ub2ZOCv0AjN6rzu66tGOTw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB6103
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.170.22
 definitions=2023-02-14_11,2023-02-14_01,2023-02-09_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0
 phishscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2212070000 definitions=main-2302140134
X-Proofpoint-GUID: MBO9QItNRht-H38Wo-qnzf57McF786_E
X-Proofpoint-ORIG-GUID: MBO9QItNRht-H38Wo-qnzf57McF786_E
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 13 Feb 2023, Bjorn Helgaas spake thusly:

> On Fri, Feb 10, 2023 at 04:47:42PM +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 comment out all uses of MODULE_LICENSE that are not in real modules
>> (the license declaration is left in as documentation).
>
> Weird that all the patches are for drivers/pci/, but the cover letter
> didn't go to linux-pci@vger.kernel.org.
>
>   - Please drop "kbuild," from the subject; I don't think it's really
>     relevant.

Every other treewide kbuild modification that I can see has a kbuild
prefix. Many of them have *nothing* else, just kbuild:, no per-subsystem
descriptor at all. If I remove the kbuild: prefix from all these
commits, will other people promptly complain? Luis?

>   - Please follow the subject line convention for each file.  They're
>     mostly there after dropping "kbuild", but do capitalize the
>     sentence that follows the prefix.  The prefix should always be
>     "PCI/<driver-tag>: "

These prefixes were automatically generated by a splitting script which
computes a prefix to apply to each commit's log by reusing the most
commonly used prefix which is present at least once in all affected
files in the subsystem (in this case, that's simple because there's just
one file).

(However, there appears to be a bug in the script here: "PCI:
generic,versatile" appears only once. I would expect "PCI: versatile",
which is used repeatedly in the history of that file. Will fix.)

I guess the convention you refer to is new, because there are a total of
zero uses of "PCI/versatile" in the entirety of git history. Are you
*sure* you want me to use that?


(More generally, I have no idea where these "driver tags" come from,
hence the weird ad-hoc approach I had to use to generate commit log
first-line prefixes when splitting this commit by subsystem. There seems
to be very little consistency here. They certainly don't come from
MAINTAINERS or from the files themselves, nor are they the filename, at
least not always. Could you give me some sort of procedure for
generating them, if picking popular prefixes from git history won't cut
it? It's essential that the process be automatable: I've had to resplit
this commit more than half a dozen times already and if I have to label
each commit by hand every time it will become a nightmare of human
error. If the rules for generating prefixes vary by subsystem this means
I'll have to fight through God knows how many annoyed maintainers to get
this incredibly trivial change in.)

>   - AFAICT, SPDX is the dispositive license and MODULE_LICENSE just
>     determines which interfaces are available to the module, so
>     dropping MODULE_LICENSE shouldn't be a problem as far as legal
>     issues.

Yeah, looks like. I'll just drop them, everyone seems to want that. If
someone dislikes my doing that they can always put a commented-out
MODULE_LICENSE back.

-- 
NULL && (void)