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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 16 Jan 2021 17:49:55 +0100 From: Marek Vasut <marex@...x.de> To: Arnd Bergmann <arnd@...nel.org>, Heiner Kallweit <hkallweit1@...il.com> Cc: Andrew Lunn <andrew@...n.ch>, 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 1/15/21 10:36 PM, Arnd Bergmann wrote: > 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. Maybe just passing THIS_MODULE around is even better way to do it, I CCed you on the V2, [PATCH net-next V2] net: ks8851: Fix mixed module/builtin build .
Powered by blists - more mailing lists