linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Nick Alcock <nick.alcock@oracle.com>
Cc: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 09/27] irqchip: remove MODULE_LICENSE in non-modules
Date: Mon, 27 Feb 2023 11:35:17 -0800	[thread overview]
Message-ID: <Y/0F9SpM1HLO4Jm/@bombadil.infradead.org> (raw)
In-Reply-To: <87v8jni6ls.fsf@esperi.org.uk>

On Mon, Feb 27, 2023 at 01:24:31PM +0000, Nick Alcock wrote:
> On 24 Feb 2023, Luis Chamberlain spake thusly:
> > Modules that are compiled in should succeed with a modprobe call as its
> > already loaded. The construct we're looking for is a way to detect
> > things which are built-in but *could* be modules. The annotation today
> > is done at build time for something built-in using a file path using
> > modinfo.
> >
> > All of the module macros which peg .modinfo section information for
> > built-in code can be extracted from vmlinux using objcopy -j .modinfo, and
> > that's exactly how modules.builtin.modinfo is built:
> >
> > objcopy -j .modinfo -O binary vmlinux.o modules.builtin.modinfo
> >
> > From this we grep out the "file:" and sed it with a ^kernel prefix.
> > You can look at the commit 8b41fc4454e ("kbuild: create modules.builtin
> > without Makefile.modbuiltin or tristate.conf") which did that.
> >
> > If a module is built-in then MODULE_FILE() is used we and we add a
> > MODULE_INFO(file, KBUILD_MODFILE), and so the modinfo exists for the
> > "file:" tag for it. At build time we sed for all those with a kernel prefix
> > to build the modules.builtin file. That file is used by modprobe to tell
> > us "yes your module is loaded as its built-in".
> >
> > So the thing we wish to not have present is when built-in code is being
> > compiled but *cannot possibly* be module, and we have no way to verify that.
> >
> > So one way to go about this is to simply *not* use the MODULE_LICENSE()
> > which cannot possibly be modules so to simplfy the build process.
> 
> I do wonder if I should drop this excellent description (up to the place
> where you start musing on alternatives) into the cover letters for the
> remaining two tranches in this series, to forestall further confusion.
> Any objection? (I doubt it, but it seems right to ask.)

Cover letters die, commit logs don't. So use it either as part of the
commit log or refer to this thread on the commit log. You can also try
to condense / paraphrase my description somehow too.

  Luis

  reply	other threads:[~2023-02-27 19:35 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230224150811.80316-1-nick.alcock@oracle.com>
2023-02-24 15:07 ` [PATCH 01/27] gpio: remove MODULE_LICENSE in non-modules Nick Alcock
2023-03-06  9:47   ` Bartosz Golaszewski
2023-02-24 15:07 ` [PATCH 02/27] hwspinlock: " Nick Alcock
2023-02-24 15:07 ` [PATCH 03/27] fbdev: " Nick Alcock
2023-02-24 15:07 ` [PATCH 04/27] mfd: intel_soc_pmic_crc: " Nick Alcock
2023-02-24 16:39   ` Andy Shevchenko
2023-03-03 11:01     ` Lee Jones
2023-03-06 17:04       ` Nick Alcock
2023-03-06 17:25         ` Andy Shevchenko
2023-03-03 11:02   ` Lee Jones
2023-02-24 15:07 ` [PATCH 05/27] cpufreq: intel_pstate: " Nick Alcock
2023-02-28 20:30   ` Rafael J. Wysocki
2023-02-24 15:07 ` [PATCH 06/27] interconnect: " Nick Alcock
2023-03-15 15:23   ` Georgi Djakov
2023-02-24 15:07 ` [PATCH 07/27] iommu/sun50i: " Nick Alcock
2023-03-14 20:15   ` Jernej Škrabec
2023-03-22 13:27   ` Joerg Roedel
2023-02-24 15:07 ` [PATCH 08/27] irqchip: " Nick Alcock
2023-02-24 15:07 ` [PATCH 09/27] " Nick Alcock
2023-02-24 15:32   ` Marc Zyngier
2023-02-24 17:21     ` Luis Chamberlain
2023-02-24 17:35       ` Marc Zyngier
2023-02-24 19:59         ` Luis Chamberlain
2023-02-27 13:24           ` Nick Alcock
2023-02-27 19:35             ` Luis Chamberlain [this message]
2023-02-27 19:37               ` Nick Alcock
2023-03-21  8:27           ` Masahiro Yamada
2023-02-24 15:07 ` [PATCH 10/27] leds: " Nick Alcock
2023-03-03 10:53   ` Lee Jones
2023-03-20 10:40     ` Nick Alcock
2023-02-24 15:07 ` [PATCH 11/27] mailbox: rockchip: " Nick Alcock
2023-02-24 15:07 ` [PATCH 12/27] mailbox: zynqmp-ipi: " Nick Alcock
2023-02-27 11:52   ` Michal Simek
2023-02-24 15:07 ` [PATCH 13/27] mctp: " Nick Alcock
2023-02-24 15:07 ` [PATCH 14/27] power: reset: mt6397: " Nick Alcock
2023-02-24 15:07 ` [PATCH 15/27] memory: tegra: " Nick Alcock
2023-03-06 14:30   ` Krzysztof Kozlowski
2023-03-06 15:45     ` Krzysztof Kozlowski
2023-03-06 17:13       ` Nick Alcock
2023-03-06 18:25         ` Krzysztof Kozlowski
2023-03-08 20:25           ` Nick Alcock
2023-03-09  6:19             ` Krzysztof Kozlowski
2023-02-24 15:08 ` [PATCH 16/27] " Nick Alcock
2023-03-06 14:28   ` (subset) " Krzysztof Kozlowski
2023-02-24 15:08 ` [PATCH 17/27] memory: " Nick Alcock
2023-03-06 14:28   ` (subset) " Krzysztof Kozlowski
2023-02-24 15:08 ` [PATCH 18/27] mtd: bcm63xxpart: " Nick Alcock
2023-03-07 19:23   ` Miquel Raynal
2023-02-24 15:08 ` [PATCH 19/27] irqchip/mchp-eic: " Nick Alcock
2023-03-03 11:23   ` Claudiu.Beznea
2023-02-24 15:08 ` [PATCH 20/27] mfd: " Nick Alcock
2023-02-24 15:08 ` [PATCH 21/27] mfd: bcm2835-pm: " Nick Alcock
2023-02-24 18:38   ` Florian Fainelli
2023-03-03 10:53   ` Lee Jones
2023-02-24 15:08 ` [PATCH 22/27] mfd: " Nick Alcock
2023-02-24 15:08 ` [PATCH 23/27] NFSv4_2: " Nick Alcock
2023-02-24 15:08 ` [PATCH 24/27] firmware: xilinx: " Nick Alcock
2023-02-27 11:51   ` Michal Simek
2023-02-24 15:08 ` [PATCH 25/27] nvmem: core: " Nick Alcock
2023-02-24 15:08 ` [PATCH 26/27] mfd: " Nick Alcock
2023-03-03 10:52   ` Lee Jones
2023-03-08 12:32     ` Nick Alcock
2023-03-08 13:04       ` Lee Jones
2023-03-08 13:07         ` Nick Alcock
2023-03-08 14:31           ` Lee Jones
2023-03-08 12:35     ` Nick Alcock
2023-02-24 15:08 ` [PATCH 27/27] lib: packing: " Nick Alcock
2023-02-24 15:22   ` Vladimir Oltean
2023-02-27 19:39     ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y/0F9SpM1HLO4Jm/@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=nick.alcock@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).