netdev - Re: [PATCH net-next] net: ks8851: Fix mixed module/builtin build

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a1A=Fa6dHvLKkqcmDwPGh2MsJfpTDwmRAjkn1++jAJUWA@mail.gmail.com>
Date:   Fri, 15 Jan 2021 22:36:12 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>, Marek Vasut <marex@...x.de>,
        Networking <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Lukas Wunner <lukas@...ner.de>
Subject: Re: [PATCH net-next] net: ks8851: Fix mixed module/builtin build

On Fri, Jan 15, 2021 at 6:24 PM Heiner Kallweit <hkallweit1@...il.com> wrote:
> On 15.01.2021 16:59, Andrew Lunn wrote:
> > On Fri, Jan 15, 2021 at 04:05:57PM +0100, Marek Vasut wrote:
> >> On 1/15/21 4:00 PM, Andrew Lunn wrote:
> >>> On Fri, Jan 15, 2021 at 02:42:39PM +0100, Marek Vasut wrote:
> >>>> When either the SPI or PAR variant is compiled as module AND the other
> >>>> variant is compiled as built-in, the following build error occurs:
> >>>>
> >>>> arm-linux-gnueabi-ld: drivers/net/ethernet/micrel/ks8851_common.o: in function `ks8851_probe_common':
> >>>> ks8851_common.c:(.text+0x1564): undefined reference to `__this_module'
> >>>>
> >>>> Fix this by including the ks8851_common.c in both ks8851_spi.c and
> >>>> ks8851_par.c. The DEBUG macro is defined in ks8851_common.c, so it
> >>>> does not have to be defined again.
> >>>
> >>> DEBUG should not be defined for production code. So i would remove it
> >>> altogether.
> >>>
> >>> There is kconfig'ury you can use to make them both the same. But i'm
> >>> not particularly good with it.
> >>
> >> We had discussion about this module/builtin topic in ks8851 before, so I was
> >> hoping someone might provide a better suggestion.
> >
> > Try Arnd Bergmann. He is good with this sort of thing.
> >
> I'd say make ks8851_common.c a separate module. Then, if one of SPI / PAR
> is built in, ks8851_common needs to be built in too. To do so you'd have
> export all symbols from ks8851_common that you want to use in SPI /PAR.

Yes, that should work, as long the common module does not reference
any symbols from the other two modules (it normally wouldn't), and all
globals in the common one are exported.

You can also link everything into a single module, but then you have
to deal with registering two device_driver structures from a single
init function, which would undo some of cleanup.

       Arnd