From: Masahiro Yamada <masahiroy@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Alexander Lobakin <alobakin@pm.me>,
linux-kbuild@vger.kernel.org, Nicolas Schier <nicolas@fjasle.eu>,
Jens Axboe <axboe@kernel.dk>,
Boris Brezillon <bbrezillon@kernel.org>,
Borislav Petkov <bp@alien8.de>, Tony Luck <tony.luck@intel.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Derek Chickles <dchickles@marvell.com>,
Ioana Ciornei <ioana.ciornei@nxp.com>,
Salil Mehta <salil.mehta@huawei.com>,
Sunil Goutham <sgoutham@marvell.com>,
Grygorii Strashko <grygorii.strashko@ti.com>,
Daniel Scally <djrscally@gmail.com>,
Mark Brown <broonie@kernel.org>,
NXP Linux Team <linux-imx@nxp.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 11/18] platform/x86: int3472: fix object shared between several modules
Date: Mon, 21 Nov 2022 18:06:15 +0900 [thread overview]
Message-ID: <CAK7LNAROUV6Z6L6yn4WiigfPRJTGU4+j0ujLt6nsxVp9+aCUzw@mail.gmail.com> (raw)
In-Reply-To: <87852fc9-0757-7e58-35a2-90cccf970f5c@redhat.com>
On Mon, Nov 21, 2022 at 5:12 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 11/21/22 00:45, Masahiro Yamada wrote:
> > On Mon, Nov 21, 2022 at 5:55 AM Hans de Goede <hdegoede@redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> On 11/20/22 14:55, Andy Shevchenko wrote:
> >>> On Sat, Nov 19, 2022 at 11:08:17PM +0000, Alexander Lobakin wrote:
> >>>> common.o is linked to both intel_skl_int3472_{discrete,tps68470}:
> >>>>
> >>>>> scripts/Makefile.build:252: ./drivers/platform/x86/intel/int3472/Makefile:
> >>>>> common.o is added to multiple modules: intel_skl_int3472_discrete
> >>>>> intel_skl_int3472_tps68470
> >>>>
> >>>> Although both drivers share one Kconfig option
> >>>> (CONFIG_INTEL_SKL_INT3472), it's better to not link one object file
> >>>> into several modules (and/or vmlinux).
> >>>> Under certain circumstances, such can lead to the situation fixed by
> >>>> commit 637a642f5ca5 ("zstd: Fixing mixed module-builtin objects").
> >>>>
> >>>> Introduce the new module, intel_skl_int3472_common, to provide the
> >>>> functions from common.o to both discrete and tps68470 drivers. This
> >>>> adds only 3 exports and doesn't provide any changes to the actual
> >>>> code.
> >>
> >> Replying to Andy's reply here since I never saw the original submission
> >> which was not Cc-ed to platform-driver-x86@vger.kernel.org .
> >>
> >> As you mention already in the commit msg, the issue from:
> >>
> >> commit 637a642f5ca5 ("zstd: Fixing mixed module-builtin objects")
> >>
> >> is not an issue here since both modules sharing the .o file are
> >> behind the same Kconfig option.
> >>
> >> So there is not really an issue here and common.o is tiny, so
> >> small chances are it does not ever increase the .ko size
> >> when looking a the .ko size rounded up to a multiple of
> >> the filesystem size.
> >>
> >> At the same time adding an extra module does come with significant
> >> costs, it will eat up at least 1 possibly more then 1 fs blocks
> >> (I don't know what the module header size overhead is).
> >>
> >> And it needs to be loaded separately and module loading is slow;
> >> and it will grow the /lib/modules/<kver>/modules.* sizes.
> >>
> >> So nack from me for this patch, since I really don't see
> >> it adding any value.
> >
> >
> >
> >
> > This does have a value.
> >
> > This clarifies the ownership of the common.o,
> > in other words, makes KBUILD_MODNAME deterministic.
> >
> >
> > If an object belongs to a module,
> > KBUILD_MODNAME is defined as the module name.
> >
> > If an object is always built-in,
> > KBUILD_MODNAME is defined as the basename of the object.
> >
> >
> >
> > Here is a question:
> > if common.o is shared by two modules intel_skl_int3472_discrete
> > and intel_skl_int3472_tps68470, what should KBUILD_MODNAME be?
> >
> >
> > I see some patch submissions relying on the assumption that
> > KBUILD_MODNAME is unique.
> > We cannot determine KBUILD_MODNAME correctly if an object is shared
> > by multiple modules.
> >
> >
> >
> >
> >
> >
> > BTW, this patch is not the way I suggested.
> > The Suggested-by should not have been there
> > (or at least Reported-by)
> >
> >
> > You argued "common.o is tiny", so I would vote for
> > making them inline functions, like
> >
> >
> > https://lore.kernel.org/linux-kbuild/20221119225650.1044591-2-alobakin@pm.me/T/#u
>
> Yes just moving the contents of common.c to static inline helpers in common.h
> would be much better.
>
> If someone creates such a patch, please do not forget to Cc
> platform-driver-x86@vger.kernel.org
I think this patch series should be split
and sent to each sub-system instead of kbuild.
> Regards,
>
> Hans
>
>
>
> >
> >
> >
> >
> >
> >
> >
> >
> >> Regards,
> >>
> >> Hans
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> ...
> >>>
> >>>> +MODULE_IMPORT_NS(INTEL_SKL_INT3472);
> >>>> +
> >>>
> >>> Redundant blank line. You may put it to be last MODULE_*() in the file, if you
> >>> think it would be more visible.
> >>>
> >>>> MODULE_DESCRIPTION("Intel SkyLake INT3472 ACPI Discrete Device Driver");
> >>>> MODULE_AUTHOR("Daniel Scally <djrscally@gmail.com>");
> >>>> MODULE_LICENSE("GPL v2");
> >>>
> >>> ...
> >>>
> >>>> +MODULE_IMPORT_NS(INTEL_SKL_INT3472);
> >>>> +
> >>>> MODULE_DESCRIPTION("Intel SkyLake INT3472 ACPI TPS68470 Device Driver");
> >>>> MODULE_AUTHOR("Daniel Scally <djrscally@gmail.com>");
> >>>> MODULE_LICENSE("GPL v2");
> >>>
> >>> Ditto. And the same to all your patches.
> >>>
> >>
> >
> >
>
--
Best Regards
Masahiro Yamada
next prev parent reply other threads:[~2022-11-21 9:07 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-19 23:03 [PATCH 00/18] treewide: fix object files shared between several modules Alexander Lobakin
2022-11-19 23:04 ` [PATCH 01/18] block/rnbd: fix mixed module-builtin object Alexander Lobakin
2022-11-21 21:17 ` Andrew Davis
2022-11-22 5:59 ` Masahiro Yamada
2022-11-29 18:24 ` Andrew Davis
2022-11-19 23:04 ` [PATCH 02/18] drm/bridge: imx: " Alexander Lobakin
2022-11-19 23:05 ` [PATCH 03/18] drm/bridge: imx: turn imx8{qm,qxp}-ldb into single-object modules Alexander Lobakin
2022-11-19 23:05 ` [PATCH 04/18] sound: fix mixed module-builtin object Alexander Lobakin
2022-11-19 23:05 ` [PATCH 05/18] mfd: rsmu: " Alexander Lobakin
2022-11-19 23:06 ` [PATCH 06/18] mfd: rsmu: turn rsmu-{core,i2c,spi} into single-object modules Alexander Lobakin
2022-11-19 23:06 ` [PATCH 07/18] net: liquidio: fix mixed module-builtin object Alexander Lobakin
2022-11-19 23:06 ` [PATCH 08/18] net: enetc: " Alexander Lobakin
2022-11-23 13:03 ` Masahiro Yamada
2022-11-19 23:07 ` [PATCH 09/18] net: emac, cpsw: fix mixed module-builtin object (davinci_cpdma) Alexander Lobakin
2022-11-23 16:04 ` Masahiro Yamada
2022-11-19 23:07 ` [PATCH 10/18] EDAC: i10nm, skx: fix mixed module-builtin object Alexander Lobakin
2022-11-23 16:12 ` Masahiro Yamada
2022-11-19 23:08 ` [PATCH 11/18] platform/x86: int3472: fix object shared between several modules Alexander Lobakin
2022-11-20 13:55 ` Andy Shevchenko
2022-11-20 20:54 ` Hans de Goede
2022-11-20 23:45 ` Masahiro Yamada
2022-11-21 8:12 ` Hans de Goede
2022-11-21 9:06 ` Masahiro Yamada [this message]
2022-11-21 9:34 ` Hans de Goede
2022-11-23 21:19 ` Alexander Lobakin
2022-11-23 21:10 ` Alexander Lobakin
2022-11-23 0:01 ` Alexander Lobakin
2022-11-19 23:08 ` [PATCH 12/18] mtd: tests: " Alexander Lobakin
2022-11-23 13:11 ` Masahiro Yamada
2022-11-23 16:59 ` Miquel Raynal
2022-11-19 23:09 ` [PATCH 13/18] crypto: octeontx2: fix objects " Alexander Lobakin
2022-11-23 16:26 ` Masahiro Yamada
2022-11-19 23:09 ` [PATCH 14/18] dsa: ocelot: fix mixed module-builtin object Alexander Lobakin
2022-11-21 17:55 ` Vladimir Oltean
2022-11-21 18:12 ` Colin Foster
2022-11-21 21:02 ` Vladimir Oltean
2022-11-23 21:31 ` Alexander Lobakin
2022-11-23 21:47 ` Alexander Lobakin
2022-11-23 22:18 ` Colin Foster
2022-11-23 22:36 ` Vladimir Oltean
2022-11-21 18:59 ` Andy Shevchenko
2022-11-19 23:09 ` [PATCH 15/18] net: dpaa2: " Alexander Lobakin
2022-11-23 21:02 ` Masahiro Yamada
2022-11-19 23:10 ` [PATCH 16/18] net: hns3: " Alexander Lobakin
2022-11-22 12:39 ` Salil Mehta
2022-11-23 22:07 ` Alexander Lobakin
2022-11-24 9:58 ` Salil Mehta
2022-11-19 23:10 ` [PATCH 17/18] net: octeontx2: " Alexander Lobakin
2022-11-23 20:54 ` Masahiro Yamada
2022-11-19 23:10 ` [PATCH 18/18] net: cpsw: " Alexander Lobakin
2022-11-23 20:37 ` Masahiro Yamada
2022-11-20 11:58 ` [PATCH 00/18] treewide: fix object files shared between several modules Mark Brown
2022-11-20 12:26 ` Conor Dooley
2022-11-22 11:28 ` Mark Brown
2022-11-22 21:37 ` Alexander Lobakin
2022-11-23 11:51 ` Mark Brown
2022-11-21 19:50 ` Jakub Kicinski
2022-11-23 21:40 ` Alexander Lobakin
2022-11-23 21:39 ` Masahiro Yamada
2023-02-10 17:31 ` Alexander Lobakin
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=CAK7LNAROUV6Z6L6yn4WiigfPRJTGU4+j0ujLt6nsxVp9+aCUzw@mail.gmail.com \
--to=masahiroy@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=alobakin@pm.me \
--cc=andriy.shevchenko@linux.intel.com \
--cc=axboe@kernel.dk \
--cc=bbrezillon@kernel.org \
--cc=bp@alien8.de \
--cc=broonie@kernel.org \
--cc=dchickles@marvell.com \
--cc=djrscally@gmail.com \
--cc=grygorii.strashko@ti.com \
--cc=hdegoede@redhat.com \
--cc=ioana.ciornei@nxp.com \
--cc=linux-imx@nxp.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas@fjasle.eu \
--cc=salil.mehta@huawei.com \
--cc=sgoutham@marvell.com \
--cc=tony.luck@intel.com \
--cc=vladimir.oltean@nxp.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).