Symbol namespaces
Subsystems (49)
Matthias Maennich
maintainerPATCH v4 12/12 RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
In reply to Matthias MaennichModules using symbols from the WATCHDOG_CORE namespace are required to explicitly import the namespace. This patch was generated with the following steps and serves as a reference to use the symbol namespace feature:
1) Use EXPORT_SYMBOL_NS* macros instead of EXPORT_SYMBOL* for symbols in watchdog_core.c
2) make (see warnings during modpost about missing imports)
3) make nsdeps
I used 'allmodconfig' for the above steps to ensure all occurrences are patched.
Defining DEFAULT_SYMBOL_NAMESPACE in the Makefile is not trivial in this case as not only watchdog_core is defined in drivers/watchdog/Makefile. Hence this patch uses the variant of using the EXPORT_SYMBOL_NS* macros to export into a different namespace.
An alternative to this patch would be a single definition line before any use of EXPORT_SYMBOL*:
#define DEFAULT_SYMBOL_NAMESPACE WATCHDOG_CORE
This patch serves as a reference on how to use the symbol namespaces.
--- drivers/hwmon/ftsteutates.c | 1 + drivers/hwmon/sch56xx-common.c | 1 + drivers/rtc/rtc-abx80x.c | 1 + drivers/watchdog/armada_37xx_wdt.c | 1 + drivers/watchdog/asm9260_wdt.c | 1 + drivers/watchdog/aspeed_wdt.c | 1 + drivers/watchdog/at91sam9_wdt.c | 1 + drivers/watchdog/atlas7_wdt.c | 1 + drivers/watchdog/bcm2835_wdt.c | 1 + drivers/watchdog/bcm47xx_wdt.c | 1 + drivers/watchdog/bcm7038_wdt.c | 1 + drivers/watchdog/bcm_kona_wdt.c | 1 + drivers/watchdog/bd70528_wdt.c | 1 + drivers/watchdog/cadence_wdt.c | 1 + drivers/watchdog/da9052_wdt.c | 1 + drivers/watchdog/da9055_wdt.c | 1 + drivers/watchdog/da9062_wdt.c | 1 + drivers/watchdog/da9063_wdt.c | 1 + drivers/watchdog/davinci_wdt.c | 1 + drivers/watchdog/digicolor_wdt.c | 1 + drivers/watchdog/dw_wdt.c | 1 + drivers/watchdog/ebc-c384_wdt.c | 1 + drivers/watchdog/ep93xx_wdt.c | 1 + drivers/watchdog/ftwdt010_wdt.c | 1 + drivers/watchdog/gpio_wdt.c | 1 + drivers/watchdog/hpwdt.c | 1 + drivers/watchdog/i6300esb.c | 1 + drivers/watchdog/iTCO_wdt.c | 1 + drivers/watchdog/ie6xx_wdt.c | 1 + drivers/watchdog/imgpdc_wdt.c | 1 + drivers/watchdog/imx2_wdt.c | 1 + drivers/watchdog/intel-mid_wdt.c | 1 + drivers/watchdog/it87_wdt.c | 1 + drivers/watchdog/kempld_wdt.c | 1 + drivers/watchdog/lpc18xx_wdt.c | 1 + drivers/watchdog/max63xx_wdt.c | 1 + drivers/watchdog/max77620_wdt.c | 1 + drivers/watchdog/mei_wdt.c | 1 + drivers/watchdog/mena21_wdt.c | 1 + drivers/watchdog/menf21bmc_wdt.c | 1 + drivers/watchdog/menz69_wdt.c | 1 + drivers/watchdog/meson_gxbb_wdt.c | 1 + drivers/watchdog/meson_wdt.c | 1 + drivers/watchdog/mlx_wdt.c | 1 + drivers/watchdog/moxart_wdt.c | 1 + drivers/watchdog/mtk_wdt.c | 1 + drivers/watchdog/ni903x_wdt.c | 1 + drivers/watchdog/nic7018_wdt.c | 1 + drivers/watchdog/npcm_wdt.c | 1 + drivers/watchdog/of_xilinx_wdt.c | 1 + drivers/watchdog/omap_wdt.c | 1 + drivers/watchdog/pm8916_wdt.c | 1 + drivers/watchdog/qcom-wdt.c | 1 + drivers/watchdog/rave-sp-wdt.c | 1 + drivers/watchdog/renesas_wdt.c | 1 + drivers/watchdog/retu_wdt.c | 1 + drivers/watchdog/rn5t618_wdt.c | 1 + drivers/watchdog/rza_wdt.c | 1 + drivers/watchdog/s3c2410_wdt.c | 1 + drivers/watchdog/sama5d4_wdt.c | 1 + drivers/watchdog/sirfsoc_wdt.c | 1 + drivers/watchdog/softdog.c | 1 + drivers/watchdog/sp5100_tco.c | 1 + drivers/watchdog/sprd_wdt.c | 1 + drivers/watchdog/st_lpc_wdt.c | 1 + drivers/watchdog/stmp3xxx_rtc_wdt.c | 1 + drivers/watchdog/stpmic1_wdt.c | 1 + drivers/watchdog/sunxi_wdt.c | 1 + drivers/watchdog/tangox_wdt.c | 1 + drivers/watchdog/tegra_wdt.c | 1 + drivers/watchdog/tqmx86_wdt.c | 1 + drivers/watchdog/ts4800_wdt.c | 1 + drivers/watchdog/ts72xx_wdt.c | 1 + drivers/watchdog/twl4030_wdt.c | 1 + drivers/watchdog/uniphier_wdt.c | 1 + drivers/watchdog/via_wdt.c | 1 + drivers/watchdog/w83627hf_wdt.c | 1 + drivers/watchdog/watchdog_core.c | 10 +++++----- drivers/watchdog/wdat_wdt.c | 1 + drivers/watchdog/wm831x_wdt.c | 1 + drivers/watchdog/wm8350_wdt.c | 1 + drivers/watchdog/xen_wdt.c | 1 + drivers/watchdog/ziirave_wdt.c | 1 + 83 files changed, 87 insertions(+), 5 deletions(-)
drivers/hwmon/ftsteutates.c +1 -0
@@ -830,3 +830,4 @@ module_i2c_driver(fts_driver);MODULE_AUTHOR ("Thilo Cestonaro <[email protected]>" );MODULE_DESCRIPTION ("FTS Teutates driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/hwmon/sch56xx-common.c +1 -0
@@ -571,6 +571,7 @@ static void __exit sch56xx_exit(void)MODULE_DESCRIPTION ("SMSC SCH56xx Hardware Monitoring Common Code" );MODULE_AUTHOR ("Hans de Goede <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );module_init (sch56xx_init);module_exit (sch56xx_exit);
drivers/rtc/rtc-abx80x.c +1 -0
@@ -880,3 +880,4 @@ MODULE_AUTHOR("Philippe De Muyter <[email protected]>");MODULE_AUTHOR ("Alexandre Belloni <[email protected]>" );MODULE_DESCRIPTION ("Abracon ABX80X RTC driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/armada_37xx_wdt.c +1 -0
@@ -370,4 +370,5 @@ MODULE_AUTHOR("Marek Behun <[email protected]>");MODULE_DESCRIPTION ("Armada 37xx CPU Watchdog" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:armada_37xx_wdt" );
drivers/watchdog/asm9260_wdt.c +1 -0
@@ -374,3 +374,4 @@ module_platform_driver(asm9260_wdt_driver);MODULE_DESCRIPTION ("asm9260 WatchDog Timer Driver" );MODULE_AUTHOR ("Oleksij Rempel <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/aspeed_wdt.c +1 -0
@@ -334,3 +334,4 @@ module_exit(aspeed_wdt_exit);MODULE_DESCRIPTION ("Aspeed Watchdog Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/at91sam9_wdt.c +1 -0
@@ -416,3 +416,4 @@ module_platform_driver_probe(at91wdt_driver, at91wdt_probe);MODULE_AUTHOR ("Renaud CERRATO <[email protected]>" );MODULE_DESCRIPTION ("Watchdog driver for Atmel AT91SAM9x processors" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/atlas7_wdt.c +1 -0
@@ -218,4 +218,5 @@ module_platform_driver(atlas7_wdt_driver);MODULE_DESCRIPTION ("CSRatlas7 watchdog driver" );MODULE_AUTHOR ("Guo Zeng <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:atlas7-wdt" );
drivers/watchdog/bcm2835_wdt.c +1 -0
@@ -242,3 +242,4 @@ MODULE_ALIAS("platform:bcm2835-wdt");MODULE_AUTHOR ("Lubomir Rintel <[email protected]>" );MODULE_DESCRIPTION ("Driver for Broadcom BCM2835 watchdog timer" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/bcm47xx_wdt.c +1 -0
@@ -241,3 +241,4 @@ MODULE_AUTHOR("Aleksandar Radovanovic");MODULE_AUTHOR ("Hauke Mehrtens <[email protected]>" );MODULE_DESCRIPTION ("Watchdog driver for Broadcom BCM47xx" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/bcm7038_wdt.c +1 -0
@@ -212,5 +212,6 @@ module_param(nowayout, bool, 0); MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_DESCRIPTION ("Driver for Broadcom 7038 SoCs Watchdog" );MODULE_AUTHOR ("Justin Chen" );
drivers/watchdog/bcm_kona_wdt.c +1 -0
@@ -339,3 +339,4 @@ MODULE_ALIAS("platform:" BCM_KONA_WDT_NAME);MODULE_AUTHOR ("Markus Mayer <[email protected]>" );MODULE_DESCRIPTION ("Broadcom Kona Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/bd70528_wdt.c +1 -0
@@ -288,3 +288,4 @@ module_platform_driver(bd70528_wdt);MODULE_AUTHOR ("Matti Vaittinen <[email protected]>" );MODULE_DESCRIPTION ("BD70528 watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/cadence_wdt.c +1 -0
@@ -438,3 +438,4 @@ module_platform_driver(cdns_wdt_driver);MODULE_AUTHOR ("Xilinx, Inc." );MODULE_DESCRIPTION ("Watchdog driver for Cadence WDT" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/da9052_wdt.c +1 -0
@@ -191,4 +191,5 @@ module_platform_driver(da9052_wdt_driver);MODULE_AUTHOR ("Anthony Olech <[email protected]>" );MODULE_DESCRIPTION ("DA9052 SM Device Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:da9052-watchdog" );
drivers/watchdog/da9055_wdt.c +1 -0
@@ -166,4 +166,5 @@ module_platform_driver(da9055_wdt_driver);MODULE_AUTHOR ("David Dajun Chen <[email protected]>" );MODULE_DESCRIPTION ("DA9055 watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:da9055-watchdog" );
drivers/watchdog/da9062_wdt.c +1 -0
@@ -232,4 +232,5 @@ module_platform_driver(da9062_wdt_driver);MODULE_AUTHOR ("S Twiss <[email protected]>" );MODULE_DESCRIPTION ("WDT device driver for Dialog DA9062 and DA9061" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:da9062-watchdog" );
drivers/watchdog/da9063_wdt.c +1 -0
@@ -239,4 +239,5 @@ module_platform_driver(da9063_wdt_driver);MODULE_AUTHOR ("Mariusz Wojtasik <[email protected]>" );MODULE_DESCRIPTION ("Watchdog driver for Dialog DA9063" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:" DA9063_DRVNAME_WATCHDOG );
drivers/watchdog/davinci_wdt.c +1 -0
@@ -274,4 +274,5 @@ MODULE_PARM_DESC(heartbeat, __MODULE_STRING(DEFAULT_HEARTBEAT));MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:davinci-wdt" );
drivers/watchdog/digicolor_wdt.c +1 -0
@@ -161,3 +161,4 @@ module_platform_driver(dc_wdt_driver);MODULE_AUTHOR ("Baruch Siach <[email protected]>" );MODULE_DESCRIPTION ("Driver for Conexant Digicolor watchdog timer" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/dw_wdt.c +1 -0
@@ -340,3 +340,4 @@ module_platform_driver(dw_wdt_driver);MODULE_AUTHOR ("Jamie Iles" );MODULE_DESCRIPTION ("Synopsys DesignWare Watchdog Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/ebc-c384_wdt.c +1 -0
@@ -139,4 +139,5 @@ module_exit(ebc_c384_wdt_exit);MODULE_AUTHOR ("William Breathitt Gray <[email protected]>" );MODULE_DESCRIPTION ("WinSystems EBC-C384 watchdog timer driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("isa:" MODULE_NAME );
drivers/watchdog/ep93xx_wdt.c +1 -0
@@ -144,3 +144,4 @@ MODULE_AUTHOR("Alessandro Zummo <[email protected]>");MODULE_AUTHOR ("H Hartley Sweeten <[email protected]>" );MODULE_DESCRIPTION ("EP93xx Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/ftwdt010_wdt.c +1 -0
@@ -227,3 +227,4 @@ module_platform_driver(ftwdt010_wdt_driver);MODULE_AUTHOR ("Linus Walleij" );MODULE_DESCRIPTION ("Watchdog driver for Faraday Technology FTWDT010" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/gpio_wdt.c +1 -0
@@ -194,3 +194,4 @@ module_platform_driver(gpio_wdt_driver);MODULE_AUTHOR ("Alexander Shiyan <[email protected]>" );MODULE_DESCRIPTION ("GPIO Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/hpwdt.c +1 -0
@@ -386,6 +386,7 @@ static struct pci_driver hpwdt_driver = {MODULE_AUTHOR ("Tom Mingarelli" );MODULE_DESCRIPTION ("hpe watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_VERSION (HPWDT_VERSION );module_param (soft_margin, int,0 );
drivers/watchdog/i6300esb.c +1 -0
@@ -351,3 +351,4 @@ module_pci_driver(esb_driver);MODULE_AUTHOR ("Ross Biro and David Härdeman" );MODULE_DESCRIPTION ("Watchdog driver for Intel 6300ESB chipsets" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/iTCO_wdt.c +1 -0
@@ -632,4 +632,5 @@ MODULE_AUTHOR("Wim Van Sebroeck <[email protected]>");MODULE_DESCRIPTION ("Intel TCO WatchDog Timer Driver" );MODULE_VERSION (DRV_VERSION );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:" DRV_NAME );
drivers/watchdog/ie6xx_wdt.c +1 -0
@@ -314,4 +314,5 @@ module_exit(ie6xx_wdt_exit);MODULE_AUTHOR ("Alexander Stein <[email protected]>" );MODULE_DESCRIPTION ("Intel Atom E6xx Watchdog Device Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:" DRIVER_NAME );
drivers/watchdog/imgpdc_wdt.c +1 -0
@@ -314,3 +314,4 @@ MODULE_AUTHOR("Jude Abraham <[email protected]>");MODULE_AUTHOR ("Naidu Tellapati <[email protected]>" );MODULE_DESCRIPTION ("Imagination Technologies PDC Watchdog Timer Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/imx2_wdt.c +1 -0
@@ -433,4 +433,5 @@ module_platform_driver_probe(imx2_wdt_driver, imx2_wdt_probe);MODULE_AUTHOR ("Wolfram Sang" );MODULE_DESCRIPTION ("Watchdog driver for IMX2 and later" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:" DRIVER_NAME );
drivers/watchdog/intel-mid_wdt.c +1 -0
@@ -181,3 +181,4 @@ module_platform_driver(mid_wdt_driver);MODULE_AUTHOR ("David Cohen <[email protected]>" );MODULE_DESCRIPTION ("Watchdog Driver for Intel MID platform" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/it87_wdt.c +1 -0
@@ -354,3 +354,4 @@ module_exit(it87_wdt_exit);MODULE_AUTHOR ("Oliver Schuster" );MODULE_DESCRIPTION ("Hardware Watchdog Device Driver for IT87xx EC-LPC I/O" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/kempld_wdt.c +1 -0
@@ -550,3 +550,4 @@ module_platform_driver(kempld_wdt_driver);MODULE_DESCRIPTION ("KEM PLD Watchdog Driver" );MODULE_AUTHOR ("Michael Brunner <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/lpc18xx_wdt.c +1 -0
@@ -316,3 +316,4 @@ module_platform_driver(lpc18xx_wdt_driver);MODULE_AUTHOR ("Ariel D'Alessandro <[email protected]>" );MODULE_DESCRIPTION ("NXP LPC18xx Watchdog Timer Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/max63xx_wdt.c +1 -0
@@ -284,3 +284,4 @@ MODULE_PARM_DESC(nodelay, "(max6373/74 only, default=0)");MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/max77620_wdt.c +1 -0
@@ -209,3 +209,4 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "MODULE_AUTHOR ("Laxman Dewangan <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/mei_wdt.c +1 -0
@@ -662,4 +662,5 @@ module_mei_cl_driver(mei_wdt_driver);MODULE_AUTHOR ("Intel Corporation" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_DESCRIPTION ("Device driver for Intel MEI iAMT watchdog" );
drivers/watchdog/mena21_wdt.c +1 -0
@@ -225,4 +225,5 @@ module_platform_driver(a21_wdt_driver);MODULE_AUTHOR ("MEN Mikro Elektronik" );MODULE_DESCRIPTION ("MEN A21 Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:a21-watchdog" );
drivers/watchdog/menf21bmc_wdt.c +1 -0
@@ -181,4 +181,5 @@ module_platform_driver(menf21bmc_wdt);MODULE_DESCRIPTION ("MEN 14F021P00 BMC Watchdog driver" );MODULE_AUTHOR ("Andreas Werner <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:menf21bmc_wdt" );
drivers/watchdog/menz69_wdt.c +1 -0
@@ -167,4 +167,5 @@ module_mcb_driver(men_z069_driver);MODULE_AUTHOR ("Johannes Thumshirn <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("mcb:16z069" );
drivers/watchdog/meson_gxbb_wdt.c +1 -0
@@ -204,3 +204,4 @@ module_platform_driver(meson_gxbb_wdt_driver);MODULE_AUTHOR ("Neil Armstrong <[email protected]>" );MODULE_DESCRIPTION ("Amlogic Meson GXBB Watchdog timer driver" );MODULE_LICENSE ("Dual BSD/GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/meson_wdt.c +1 -0
@@ -228,5 +228,6 @@ MODULE_PARM_DESC(nowayout, __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Carlo Caione <[email protected]>" );MODULE_DESCRIPTION ("Meson Watchdog Timer Driver" );
drivers/watchdog/mlx_wdt.c +1 -0
@@ -287,4 +287,5 @@ module_platform_driver(mlxreg_wdt_driver);MODULE_AUTHOR ("Michael Shych <[email protected]>" );MODULE_DESCRIPTION ("Mellanox watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:mlx-wdt" );
drivers/watchdog/moxart_wdt.c +1 -0
@@ -164,4 +164,5 @@ MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");MODULE_DESCRIPTION ("MOXART watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Jonas Jensen <[email protected]>" );
drivers/watchdog/mtk_wdt.c +1 -0
@@ -247,6 +247,7 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Matthias Brugger <[email protected]>" );MODULE_DESCRIPTION ("Mediatek WatchDog Timer Driver" );MODULE_VERSION (DRV_VERSION );
drivers/watchdog/ni903x_wdt.c +1 -0
@@ -255,3 +255,4 @@ MODULE_DESCRIPTION("NI 903x Watchdog");MODULE_AUTHOR ("Jeff Westfahl <[email protected]>" );MODULE_AUTHOR ("Kyle Roeschley <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/nic7018_wdt.c +1 -0
@@ -250,3 +250,4 @@ module_platform_driver(watchdog_driver);MODULE_DESCRIPTION ("National Instruments NIC7018 Watchdog driver" );MODULE_AUTHOR ("Hui Chun Ong <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/npcm_wdt.c +1 -0
@@ -248,3 +248,4 @@ module_platform_driver(npcm_wdt_driver);MODULE_AUTHOR ("Joel Stanley" );MODULE_DESCRIPTION ("Watchdog driver for NPCM" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/of_xilinx_wdt.c +1 -0
@@ -308,3 +308,4 @@ module_platform_driver(xwdt_driver);MODULE_AUTHOR ("Alejandro Cabrera <[email protected]>" );MODULE_DESCRIPTION ("Xilinx Watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/omap_wdt.c +1 -0
@@ -375,4 +375,5 @@ module_platform_driver(omap_wdt_driver);MODULE_AUTHOR ("George G. Davis" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:omap_wdt" );
drivers/watchdog/pm8916_wdt.c +1 -0
@@ -210,3 +210,4 @@ module_platform_driver(pm8916_wdt_driver);MODULE_AUTHOR ("Loic Poulain <[email protected]>" );MODULE_DESCRIPTION ("Qualcomm pm8916 watchdog driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/qcom-wdt.c +1 -0
@@ -272,3 +272,4 @@ module_platform_driver(qcom_watchdog_driver);MODULE_DESCRIPTION ("QCOM KPSS Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/rave-sp-wdt.c +1 -0
@@ -329,6 +329,7 @@ module_platform_driver(rave_sp_wdt_driver);MODULE_DEVICE_TABLE (of, rave_sp_wdt_of_match);MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Andrey Vostrikov <[email protected]>" );MODULE_AUTHOR ("Nikita Yushchenko <[email protected]>" );MODULE_AUTHOR ("Andrey Smirnov <[email protected]>" );
drivers/watchdog/renesas_wdt.c +1 -0
@@ -315,4 +315,5 @@ module_platform_driver(rwdt_driver);MODULE_DESCRIPTION ("Renesas WDT Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Wolfram Sang <[email protected]>" );
drivers/watchdog/retu_wdt.c +1 -0
@@ -168,3 +168,4 @@ MODULE_DESCRIPTION("Retu watchdog");MODULE_AUTHOR ("Amit Kucheria" );MODULE_AUTHOR ("Aaro Koskinen <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/rn5t618_wdt.c +1 -0
@@ -191,3 +191,4 @@ module_platform_driver(rn5t618_wdt_driver);MODULE_AUTHOR ("Beniamino Galvani <[email protected]>" );MODULE_DESCRIPTION ("RN5T618 watchdog driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/rza_wdt.c +1 -0
@@ -245,3 +245,4 @@ module_platform_driver(rza_wdt_driver);MODULE_DESCRIPTION ("Renesas RZ/A WDT Driver" );MODULE_AUTHOR ("Chris Brandt <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/s3c2410_wdt.c +1 -0
@@ -739,3 +739,4 @@ module_platform_driver(s3c2410wdt_driver);MODULE_AUTHOR ("Ben Dooks <[email protected]>, Dimitry Andric <[email protected]>" );MODULE_DESCRIPTION ("S3C2410 Watchdog Device Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/sama5d4_wdt.c +1 -0
@@ -321,3 +321,4 @@ module_platform_driver(sama5d4_wdt_driver);MODULE_AUTHOR ("Atmel Corporation" );MODULE_DESCRIPTION ("Atmel SAMA5D4 Watchdog Timer driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/sirfsoc_wdt.c +1 -0
@@ -213,4 +213,5 @@ module_platform_driver(sirfsoc_wdt_driver);MODULE_DESCRIPTION ("SiRF SoC watchdog driver" );MODULE_AUTHOR ("Xianglong Du <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:sirfsoc-wdt" );
drivers/watchdog/softdog.c +1 -0
@@ -165,3 +165,4 @@ module_exit(softdog_exit);MODULE_AUTHOR ("Alan Cox" );MODULE_DESCRIPTION ("Software Watchdog Device Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/sp5100_tco.c +1 -0
@@ -486,3 +486,4 @@ module_exit(sp5100_tco_exit);MODULE_AUTHOR ("Priyanka Gupta" );MODULE_DESCRIPTION ("TCO timer driver for SP5100/SB800 chipset" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/sprd_wdt.c +1 -0
@@ -384,3 +384,4 @@ module_platform_driver(sprd_watchdog_driver);MODULE_AUTHOR ("Eric Long <[email protected]>" );MODULE_DESCRIPTION ("Spreadtrum Watchdog Timer Controller Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/st_lpc_wdt.c +1 -0
@@ -305,3 +305,4 @@ module_platform_driver(st_wdog_driver);MODULE_AUTHOR ("David Paris <[email protected]>" );MODULE_DESCRIPTION ("ST LPC Watchdog Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/stmp3xxx_rtc_wdt.c +1 -0
@@ -150,4 +150,5 @@ module_platform_driver(stmp3xxx_wdt_driver);MODULE_DESCRIPTION ("STMP3XXX RTC Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Wolfram Sang <[email protected]>" );
drivers/watchdog/stpmic1_wdt.c +1 -0
@@ -138,3 +138,4 @@ module_platform_driver(stpmic1_wdt_driver);MODULE_DESCRIPTION ("Watchdog driver for STPMIC1 device" );MODULE_AUTHOR ("Pascal Paillet <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/sunxi_wdt.c +1 -0
@@ -289,6 +289,7 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started " "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Carlo Caione <[email protected]>" );MODULE_AUTHOR ("Henrik Nordstrom <[email protected]>" );MODULE_DESCRIPTION ("sunxi WatchDog Timer Driver" );
drivers/watchdog/tangox_wdt.c +1 -0
@@ -207,3 +207,4 @@ module_platform_driver(tangox_wdt_driver);MODULE_AUTHOR ("Mans Rullgard <[email protected]>" );MODULE_DESCRIPTION ("SMP86xx/SMP87xx Watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/tegra_wdt.c +1 -0
@@ -276,3 +276,4 @@ module_platform_driver(tegra_wdt_driver);MODULE_AUTHOR ("NVIDIA Corporation" );MODULE_DESCRIPTION ("Tegra Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/tqmx86_wdt.c +1 -0
@@ -124,3 +124,4 @@ MODULE_AUTHOR("Andrew Lunn <[email protected]>");MODULE_DESCRIPTION ("TQMx86 Watchdog" );MODULE_ALIAS ("platform:tqmx86-wdt" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/ts4800_wdt.c +1 -0
@@ -200,4 +200,5 @@ module_platform_driver(ts4800_wdt_driver);MODULE_AUTHOR ("Damien Riegel <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:ts4800_wdt" );
drivers/watchdog/ts72xx_wdt.c +1 -0
@@ -174,4 +174,5 @@ module_platform_driver(ts72xx_wdt_driver);MODULE_AUTHOR ("Mika Westerberg <[email protected]>" );MODULE_DESCRIPTION ("TS-72xx SBC Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:ts72xx-wdt" );
drivers/watchdog/twl4030_wdt.c +1 -0
@@ -123,5 +123,6 @@ module_platform_driver(twl4030_wdt_driver);MODULE_AUTHOR ("Nokia Corporation" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:twl4030_wdt" );
drivers/watchdog/uniphier_wdt.c +1 -0
@@ -255,3 +255,4 @@ MODULE_PARM_DESC(nowayout,MODULE_AUTHOR ("Keiji Hayashibara <[email protected]>" );MODULE_DESCRIPTION ("UniPhier Watchdog Device Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/via_wdt.c +1 -0
@@ -259,3 +259,4 @@ module_pci_driver(wdt_driver);MODULE_AUTHOR ("Marc Vertes" );MODULE_DESCRIPTION ("Driver for watchdog timer on VIA chipset" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/w83627hf_wdt.c +1 -0
@@ -528,5 +528,6 @@ module_init(wdt_init);module_exit (wdt_exit);MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Pádraig Brady <[email protected]>" );MODULE_DESCRIPTION ("w83627hf/thf WDT driver" );
drivers/watchdog/watchdog_core.c +5 -5
@@ -145,7 +145,7 @@ int watchdog_init_timeout(struct watchdog_device *wdd,return ret; } -EXPORT_SYMBOL_GPL (watchdog_init_timeout); +EXPORT_SYMBOL_NS_GPL (watchdog_init_timeout,WATCHDOG_CORE );static int watchdog_restart_notifier (struct notifier_block *nb,unsigned long action,void *data)
@@ -180,7 +180,7 @@ void watchdog_set_restart_priority(struct watchdog_device *wdd, int priority) { wdd->restart_nb.priority = priority; } -EXPORT_SYMBOL_GPL (watchdog_set_restart_priority); +EXPORT_SYMBOL_NS_GPL (watchdog_set_restart_priority,WATCHDOG_CORE );static int __watchdog_register_device (struct watchdog_device *wdd) {
@@ -279,7 +279,7 @@ int watchdog_register_device(struct watchdog_device *wdd)return ret; } -EXPORT_SYMBOL_GPL (watchdog_register_device); +EXPORT_SYMBOL_NS_GPL (watchdog_register_device,WATCHDOG_CORE );static void __watchdog_unregister_device (struct watchdog_device *wdd) {
@@ -311,7 +311,7 @@ void watchdog_unregister_device(struct watchdog_device *wdd)mutex_unlock (&wtd_deferred_reg_mutex); } -EXPORT_SYMBOL_GPL (watchdog_unregister_device); +EXPORT_SYMBOL_NS_GPL (watchdog_unregister_device,WATCHDOG_CORE );static void devm_watchdog_unregister_device (struct device *dev,void *res) {
@@ -348,7 +348,7 @@ int devm_watchdog_register_device(struct device *dev,return ret; } -EXPORT_SYMBOL_GPL (devm_watchdog_register_device); +EXPORT_SYMBOL_NS_GPL (devm_watchdog_register_device,WATCHDOG_CORE );static int __init watchdog_deferred_registration (void ) {
drivers/watchdog/wdat_wdt.c +1 -0
@@ -523,4 +523,5 @@ module_platform_driver(wdat_wdt_driver);MODULE_AUTHOR ("Mika Westerberg <[email protected]>" );MODULE_DESCRIPTION ("ACPI Hardware Watchdog (WDAT) driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:wdat_wdt" );
drivers/watchdog/wm831x_wdt.c +1 -0
@@ -282,4 +282,5 @@ module_platform_driver(wm831x_wdt_driver);MODULE_AUTHOR ("Mark Brown" );MODULE_DESCRIPTION ("WM831x Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:wm831x-watchdog" );
drivers/watchdog/wm8350_wdt.c +1 -0
@@ -175,4 +175,5 @@ module_platform_driver(wm8350_wdt_driver);MODULE_AUTHOR ("Mark Brown" );MODULE_DESCRIPTION ("WM8350 Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:wm8350-wdt" );
drivers/watchdog/xen_wdt.c +1 -0
@@ -206,3 +206,4 @@ module_exit(xen_wdt_cleanup_module);MODULE_AUTHOR ("Jan Beulich <[email protected]>" );MODULE_DESCRIPTION ("Xen WatchDog Timer Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
drivers/watchdog/ziirave_wdt.c +1 -0
@@ -751,3 +751,4 @@ module_i2c_driver(ziirave_wdt_driver);MODULE_AUTHOR ("Martyn Welch <[email protected]" );MODULE_DESCRIPTION ("Zodiac Aerospace RAVE Switch Watchdog Processor Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Guenter Roeck
maintainerRe: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
Quoted 18 lines · Matthias Maennich
Modules using symbols from the
WATCHDOG_COREnamespace are required to explicitly import the namespace. This patch was generated with the following steps and serves as a reference to use the symbol namespace feature:1) Use EXPORT_SYMBOL_NS* macros instead of EXPORT_SYMBOL* for symbols in
watchdog_core.c
2) make (see warnings during modpost about missing imports)
3) make nsdepsI used 'allmodconfig' for the above steps to ensure all occurrences are patched.
Defining
DEFAULT_SYMBOL_NAMESPACEin theMakefileis not trivial in this case as not onlywatchdog_coreis defined indrivers/watchdog/Makefile. Hence this patch uses the variant of using the EXPORT_SYMBOL_NS* macros to export into a different namespace.
Quoted 8 lines
An alternative to this patch would be a single definition line before any use of EXPORT_SYMBOL*:
#defineDEFAULT_SYMBOL_NAMESPACEWATCHDOG_COREThis patch serves as a reference on how to use the symbol namespaces.
Reviewed-by Greg Kroah-Hartman <[email protected]>Signed-off-by Matthias Maennich <[email protected]>
As mentioned before, I am opposed to this set of changes. I don't see the point of restricting the use of exported symbols in WATCHDOG_CORE.
Guenter
Quoted 925 lines
--- drivers/hwmon/ftsteutates.c | 1 + drivers/hwmon/sch56xx-common.c | 1 + drivers/rtc/rtc-abx80x.c | 1 + drivers/watchdog/armada_37xx_wdt.c | 1 + drivers/watchdog/asm9260_wdt.c | 1 + drivers/watchdog/aspeed_wdt.c | 1 + drivers/watchdog/at91sam9_wdt.c | 1 + drivers/watchdog/atlas7_wdt.c | 1 + drivers/watchdog/bcm2835_wdt.c | 1 + drivers/watchdog/bcm47xx_wdt.c | 1 + drivers/watchdog/bcm7038_wdt.c | 1 + drivers/watchdog/bcm_kona_wdt.c | 1 + drivers/watchdog/bd70528_wdt.c | 1 + drivers/watchdog/cadence_wdt.c | 1 + drivers/watchdog/da9052_wdt.c | 1 + drivers/watchdog/da9055_wdt.c | 1 + drivers/watchdog/da9062_wdt.c | 1 + drivers/watchdog/da9063_wdt.c | 1 + drivers/watchdog/davinci_wdt.c | 1 + drivers/watchdog/digicolor_wdt.c | 1 + drivers/watchdog/dw_wdt.c | 1 + drivers/watchdog/ebc-c384_wdt.c | 1 + drivers/watchdog/ep93xx_wdt.c | 1 + drivers/watchdog/ftwdt010_wdt.c | 1 + drivers/watchdog/gpio_wdt.c | 1 + drivers/watchdog/hpwdt.c | 1 + drivers/watchdog/i6300esb.c | 1 + drivers/watchdog/iTCO_wdt.c | 1 + drivers/watchdog/ie6xx_wdt.c | 1 + drivers/watchdog/imgpdc_wdt.c | 1 + drivers/watchdog/imx2_wdt.c | 1 + drivers/watchdog/intel-mid_wdt.c | 1 + drivers/watchdog/it87_wdt.c | 1 + drivers/watchdog/kempld_wdt.c | 1 + drivers/watchdog/lpc18xx_wdt.c | 1 + drivers/watchdog/max63xx_wdt.c | 1 + drivers/watchdog/max77620_wdt.c | 1 + drivers/watchdog/mei_wdt.c | 1 + drivers/watchdog/mena21_wdt.c | 1 + drivers/watchdog/menf21bmc_wdt.c | 1 + drivers/watchdog/menz69_wdt.c | 1 + drivers/watchdog/meson_gxbb_wdt.c | 1 + drivers/watchdog/meson_wdt.c | 1 + drivers/watchdog/mlx_wdt.c | 1 + drivers/watchdog/moxart_wdt.c | 1 + drivers/watchdog/mtk_wdt.c | 1 + drivers/watchdog/ni903x_wdt.c | 1 + drivers/watchdog/nic7018_wdt.c | 1 + drivers/watchdog/npcm_wdt.c | 1 + drivers/watchdog/of_xilinx_wdt.c | 1 + drivers/watchdog/omap_wdt.c | 1 + drivers/watchdog/pm8916_wdt.c | 1 + drivers/watchdog/qcom-wdt.c | 1 + drivers/watchdog/rave-sp-wdt.c | 1 + drivers/watchdog/renesas_wdt.c | 1 + drivers/watchdog/retu_wdt.c | 1 + drivers/watchdog/rn5t618_wdt.c | 1 + drivers/watchdog/rza_wdt.c | 1 + drivers/watchdog/s3c2410_wdt.c | 1 + drivers/watchdog/sama5d4_wdt.c | 1 + drivers/watchdog/sirfsoc_wdt.c | 1 + drivers/watchdog/softdog.c | 1 + drivers/watchdog/sp5100_tco.c | 1 + drivers/watchdog/sprd_wdt.c | 1 + drivers/watchdog/st_lpc_wdt.c | 1 + drivers/watchdog/stmp3xxx_rtc_wdt.c | 1 + drivers/watchdog/stpmic1_wdt.c | 1 + drivers/watchdog/sunxi_wdt.c | 1 + drivers/watchdog/tangox_wdt.c | 1 + drivers/watchdog/tegra_wdt.c | 1 + drivers/watchdog/tqmx86_wdt.c | 1 + drivers/watchdog/ts4800_wdt.c | 1 + drivers/watchdog/ts72xx_wdt.c | 1 + drivers/watchdog/twl4030_wdt.c | 1 + drivers/watchdog/uniphier_wdt.c | 1 + drivers/watchdog/via_wdt.c | 1 + drivers/watchdog/w83627hf_wdt.c | 1 + drivers/watchdog/watchdog_core.c | 10 +++++----- drivers/watchdog/wdat_wdt.c | 1 + drivers/watchdog/wm831x_wdt.c | 1 + drivers/watchdog/wm8350_wdt.c | 1 + drivers/watchdog/xen_wdt.c | 1 + drivers/watchdog/ziirave_wdt.c | 1 + 83 files changed, 87 insertions(+), 5 deletions(-)drivers/hwmon/ftsteutates.c +1
-0@@ -830,3 +830,4 @@ module_i2c_driver(fts_driver);MODULE_AUTHOR ("Thilo Cestonaro <[email protected]>" );MODULE_DESCRIPTION ("FTS Teutates driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/hwmon/sch56xx-common.c +1
-0@@ -571,6 +571,7 @@ static void __exit sch56xx_exit(void)MODULE_DESCRIPTION ("SMSC SCH56xx Hardware Monitoring Common Code" );MODULE_AUTHOR ("Hans de Goede <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );module_init (sch56xx_init);module_exit (sch56xx_exit);drivers/rtc/rtc-abx80x.c +1
-0@@ -880,3 +880,4 @@ MODULE_AUTHOR("Philippe De Muyter <[email protected]>");MODULE_AUTHOR ("Alexandre Belloni <[email protected]>" );MODULE_DESCRIPTION ("Abracon ABX80X RTC driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/armada_37xx_wdt.c +1
-0@@ -370,4 +370,5 @@ MODULE_AUTHOR("Marek Behun <[email protected]>");MODULE_DESCRIPTION ("Armada 37xx CPU Watchdog" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:armada_37xx_wdt" );drivers/watchdog/asm9260_wdt.c +1
-0@@ -374,3 +374,4 @@ module_platform_driver(asm9260_wdt_driver);MODULE_DESCRIPTION ("asm9260 WatchDog Timer Driver" );MODULE_AUTHOR ("Oleksij Rempel <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/aspeed_wdt.c +1
-0@@ -334,3 +334,4 @@ module_exit(aspeed_wdt_exit);MODULE_DESCRIPTION ("Aspeed Watchdog Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/at91sam9_wdt.c +1
-0@@ -416,3 +416,4 @@ module_platform_driver_probe(at91wdt_driver, at91wdt_probe);MODULE_AUTHOR ("Renaud CERRATO <[email protected]>" );MODULE_DESCRIPTION ("Watchdog driver for Atmel AT91SAM9x processors" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/atlas7_wdt.c +1
-0@@ -218,4 +218,5 @@ module_platform_driver(atlas7_wdt_driver);MODULE_DESCRIPTION ("CSRatlas7 watchdog driver" );MODULE_AUTHOR ("Guo Zeng <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:atlas7-wdt" );drivers/watchdog/bcm2835_wdt.c +1
-0@@ -242,3 +242,4 @@ MODULE_ALIAS("platform:bcm2835-wdt");MODULE_AUTHOR ("Lubomir Rintel <[email protected]>" );MODULE_DESCRIPTION ("Driver for Broadcom BCM2835 watchdog timer" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/bcm47xx_wdt.c +1
-0@@ -241,3 +241,4 @@ MODULE_AUTHOR("Aleksandar Radovanovic");MODULE_AUTHOR ("Hauke Mehrtens <[email protected]>" );MODULE_DESCRIPTION ("Watchdog driver for Broadcom BCM47xx" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/bcm7038_wdt.c +1
-0@@ -212,5 +212,6 @@ module_param(nowayout, bool, 0); MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_DESCRIPTION ("Driver for Broadcom 7038 SoCs Watchdog" );MODULE_AUTHOR ("Justin Chen" );drivers/watchdog/bcm_kona_wdt.c +1
-0@@ -339,3 +339,4 @@ MODULE_ALIAS("platform:" BCM_KONA_WDT_NAME);MODULE_AUTHOR ("Markus Mayer <[email protected]>" );MODULE_DESCRIPTION ("Broadcom Kona Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/bd70528_wdt.c +1
-0@@ -288,3 +288,4 @@ module_platform_driver(bd70528_wdt);MODULE_AUTHOR ("Matti Vaittinen <[email protected]>" );MODULE_DESCRIPTION ("BD70528 watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/cadence_wdt.c +1
-0@@ -438,3 +438,4 @@ module_platform_driver(cdns_wdt_driver);MODULE_AUTHOR ("Xilinx, Inc." );MODULE_DESCRIPTION ("Watchdog driver for Cadence WDT" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/da9052_wdt.c +1
-0@@ -191,4 +191,5 @@ module_platform_driver(da9052_wdt_driver);MODULE_AUTHOR ("Anthony Olech <[email protected]>" );MODULE_DESCRIPTION ("DA9052 SM Device Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:da9052-watchdog" );drivers/watchdog/da9055_wdt.c +1
-0@@ -166,4 +166,5 @@ module_platform_driver(da9055_wdt_driver);MODULE_AUTHOR ("David Dajun Chen <[email protected]>" );MODULE_DESCRIPTION ("DA9055 watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:da9055-watchdog" );drivers/watchdog/da9062_wdt.c +1
-0@@ -232,4 +232,5 @@ module_platform_driver(da9062_wdt_driver);MODULE_AUTHOR ("S Twiss <[email protected]>" );MODULE_DESCRIPTION ("WDT device driver for Dialog DA9062 and DA9061" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:da9062-watchdog" );drivers/watchdog/da9063_wdt.c +1
-0@@ -239,4 +239,5 @@ module_platform_driver(da9063_wdt_driver);MODULE_AUTHOR ("Mariusz Wojtasik <[email protected]>" );MODULE_DESCRIPTION ("Watchdog driver for Dialog DA9063" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:" DA9063_DRVNAME_WATCHDOG );drivers/watchdog/davinci_wdt.c +1
-0@@ -274,4 +274,5 @@ MODULE_PARM_DESC(heartbeat, __MODULE_STRING(DEFAULT_HEARTBEAT));MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:davinci-wdt" );drivers/watchdog/digicolor_wdt.c +1
-0@@ -161,3 +161,4 @@ module_platform_driver(dc_wdt_driver);MODULE_AUTHOR ("Baruch Siach <[email protected]>" );MODULE_DESCRIPTION ("Driver for Conexant Digicolor watchdog timer" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/dw_wdt.c +1
-0@@ -340,3 +340,4 @@ module_platform_driver(dw_wdt_driver);MODULE_AUTHOR ("Jamie Iles" );MODULE_DESCRIPTION ("Synopsys DesignWare Watchdog Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/ebc-c384_wdt.c +1
-0@@ -139,4 +139,5 @@ module_exit(ebc_c384_wdt_exit);MODULE_AUTHOR ("William Breathitt Gray <[email protected]>" );MODULE_DESCRIPTION ("WinSystems EBC-C384 watchdog timer driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("isa:" MODULE_NAME );drivers/watchdog/ep93xx_wdt.c +1
-0@@ -144,3 +144,4 @@ MODULE_AUTHOR("Alessandro Zummo <[email protected]>");MODULE_AUTHOR ("H Hartley Sweeten <[email protected]>" );MODULE_DESCRIPTION ("EP93xx Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/ftwdt010_wdt.c +1
-0@@ -227,3 +227,4 @@ module_platform_driver(ftwdt010_wdt_driver);MODULE_AUTHOR ("Linus Walleij" );MODULE_DESCRIPTION ("Watchdog driver for Faraday Technology FTWDT010" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/gpio_wdt.c +1
-0@@ -194,3 +194,4 @@ module_platform_driver(gpio_wdt_driver);MODULE_AUTHOR ("Alexander Shiyan <[email protected]>" );MODULE_DESCRIPTION ("GPIO Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/hpwdt.c +1
-0@@ -386,6 +386,7 @@ static struct pci_driver hpwdt_driver = {MODULE_AUTHOR ("Tom Mingarelli" );MODULE_DESCRIPTION ("hpe watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_VERSION (HPWDT_VERSION );module_param (soft_margin, int,0 );drivers/watchdog/i6300esb.c +1
-0@@ -351,3 +351,4 @@ module_pci_driver(esb_driver);MODULE_AUTHOR ("Ross Biro and David Härdeman" );MODULE_DESCRIPTION ("Watchdog driver for Intel 6300ESB chipsets" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/iTCO_wdt.c +1
-0@@ -632,4 +632,5 @@ MODULE_AUTHOR("Wim Van Sebroeck <[email protected]>");MODULE_DESCRIPTION ("Intel TCO WatchDog Timer Driver" );MODULE_VERSION (DRV_VERSION );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:" DRV_NAME );drivers/watchdog/ie6xx_wdt.c +1
-0@@ -314,4 +314,5 @@ module_exit(ie6xx_wdt_exit);MODULE_AUTHOR ("Alexander Stein <[email protected]>" );MODULE_DESCRIPTION ("Intel Atom E6xx Watchdog Device Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:" DRIVER_NAME );drivers/watchdog/imgpdc_wdt.c +1
-0@@ -314,3 +314,4 @@ MODULE_AUTHOR("Jude Abraham <[email protected]>");MODULE_AUTHOR ("Naidu Tellapati <[email protected]>" );MODULE_DESCRIPTION ("Imagination Technologies PDC Watchdog Timer Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/imx2_wdt.c +1
-0@@ -433,4 +433,5 @@ module_platform_driver_probe(imx2_wdt_driver, imx2_wdt_probe);MODULE_AUTHOR ("Wolfram Sang" );MODULE_DESCRIPTION ("Watchdog driver for IMX2 and later" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:" DRIVER_NAME );drivers/watchdog/intel-mid_wdt.c +1
-0@@ -181,3 +181,4 @@ module_platform_driver(mid_wdt_driver);MODULE_AUTHOR ("David Cohen <[email protected]>" );MODULE_DESCRIPTION ("Watchdog Driver for Intel MID platform" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/it87_wdt.c +1
-0@@ -354,3 +354,4 @@ module_exit(it87_wdt_exit);MODULE_AUTHOR ("Oliver Schuster" );MODULE_DESCRIPTION ("Hardware Watchdog Device Driver for IT87xx EC-LPC I/O" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/kempld_wdt.c +1
-0@@ -550,3 +550,4 @@ module_platform_driver(kempld_wdt_driver);MODULE_DESCRIPTION ("KEM PLD Watchdog Driver" );MODULE_AUTHOR ("Michael Brunner <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/lpc18xx_wdt.c +1
-0@@ -316,3 +316,4 @@ module_platform_driver(lpc18xx_wdt_driver);MODULE_AUTHOR ("Ariel D'Alessandro <[email protected]>" );MODULE_DESCRIPTION ("NXP LPC18xx Watchdog Timer Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/max63xx_wdt.c +1
-0@@ -284,3 +284,4 @@ MODULE_PARM_DESC(nodelay, "(max6373/74 only, default=0)");MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/max77620_wdt.c +1
-0@@ -209,3 +209,4 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "MODULE_AUTHOR ("Laxman Dewangan <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/mei_wdt.c +1
-0@@ -662,4 +662,5 @@ module_mei_cl_driver(mei_wdt_driver);MODULE_AUTHOR ("Intel Corporation" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_DESCRIPTION ("Device driver for Intel MEI iAMT watchdog" );drivers/watchdog/mena21_wdt.c +1
-0@@ -225,4 +225,5 @@ module_platform_driver(a21_wdt_driver);MODULE_AUTHOR ("MEN Mikro Elektronik" );MODULE_DESCRIPTION ("MEN A21 Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:a21-watchdog" );drivers/watchdog/menf21bmc_wdt.c +1
-0@@ -181,4 +181,5 @@ module_platform_driver(menf21bmc_wdt);MODULE_DESCRIPTION ("MEN 14F021P00 BMC Watchdog driver" );MODULE_AUTHOR ("Andreas Werner <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:menf21bmc_wdt" );drivers/watchdog/menz69_wdt.c +1
-0@@ -167,4 +167,5 @@ module_mcb_driver(men_z069_driver);MODULE_AUTHOR ("Johannes Thumshirn <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("mcb:16z069" );drivers/watchdog/meson_gxbb_wdt.c +1
-0@@ -204,3 +204,4 @@ module_platform_driver(meson_gxbb_wdt_driver);MODULE_AUTHOR ("Neil Armstrong <[email protected]>" );MODULE_DESCRIPTION ("Amlogic Meson GXBB Watchdog timer driver" );MODULE_LICENSE ("Dual BSD/GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/meson_wdt.c +1
-0@@ -228,5 +228,6 @@ MODULE_PARM_DESC(nowayout, __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Carlo Caione <[email protected]>" );MODULE_DESCRIPTION ("Meson Watchdog Timer Driver" );drivers/watchdog/mlx_wdt.c +1
-0@@ -287,4 +287,5 @@ module_platform_driver(mlxreg_wdt_driver);MODULE_AUTHOR ("Michael Shych <[email protected]>" );MODULE_DESCRIPTION ("Mellanox watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:mlx-wdt" );drivers/watchdog/moxart_wdt.c +1
-0@@ -164,4 +164,5 @@ MODULE_PARM_DESC(heartbeat, "Watchdog heartbeat in seconds");MODULE_DESCRIPTION ("MOXART watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Jonas Jensen <[email protected]>" );drivers/watchdog/mtk_wdt.c +1
-0@@ -247,6 +247,7 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Matthias Brugger <[email protected]>" );MODULE_DESCRIPTION ("Mediatek WatchDog Timer Driver" );MODULE_VERSION (DRV_VERSION );drivers/watchdog/ni903x_wdt.c +1
-0@@ -255,3 +255,4 @@ MODULE_DESCRIPTION("NI 903x Watchdog");MODULE_AUTHOR ("Jeff Westfahl <[email protected]>" );MODULE_AUTHOR ("Kyle Roeschley <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/nic7018_wdt.c +1
-0@@ -250,3 +250,4 @@ module_platform_driver(watchdog_driver);MODULE_DESCRIPTION ("National Instruments NIC7018 Watchdog driver" );MODULE_AUTHOR ("Hui Chun Ong <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/npcm_wdt.c +1
-0@@ -248,3 +248,4 @@ module_platform_driver(npcm_wdt_driver);MODULE_AUTHOR ("Joel Stanley" );MODULE_DESCRIPTION ("Watchdog driver for NPCM" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/of_xilinx_wdt.c +1
-0@@ -308,3 +308,4 @@ module_platform_driver(xwdt_driver);MODULE_AUTHOR ("Alejandro Cabrera <[email protected]>" );MODULE_DESCRIPTION ("Xilinx Watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/omap_wdt.c +1
-0@@ -375,4 +375,5 @@ module_platform_driver(omap_wdt_driver);MODULE_AUTHOR ("George G. Davis" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:omap_wdt" );drivers/watchdog/pm8916_wdt.c +1
-0@@ -210,3 +210,4 @@ module_platform_driver(pm8916_wdt_driver);MODULE_AUTHOR ("Loic Poulain <[email protected]>" );MODULE_DESCRIPTION ("Qualcomm pm8916 watchdog driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/qcom-wdt.c +1
-0@@ -272,3 +272,4 @@ module_platform_driver(qcom_watchdog_driver);MODULE_DESCRIPTION ("QCOM KPSS Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/rave-sp-wdt.c +1
-0@@ -329,6 +329,7 @@ module_platform_driver(rave_sp_wdt_driver);MODULE_DEVICE_TABLE (of, rave_sp_wdt_of_match);MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Andrey Vostrikov <[email protected]>" );MODULE_AUTHOR ("Nikita Yushchenko <[email protected]>" );MODULE_AUTHOR ("Andrey Smirnov <[email protected]>" );drivers/watchdog/renesas_wdt.c +1
-0@@ -315,4 +315,5 @@ module_platform_driver(rwdt_driver);MODULE_DESCRIPTION ("Renesas WDT Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Wolfram Sang <[email protected]>" );drivers/watchdog/retu_wdt.c +1
-0@@ -168,3 +168,4 @@ MODULE_DESCRIPTION("Retu watchdog");MODULE_AUTHOR ("Amit Kucheria" );MODULE_AUTHOR ("Aaro Koskinen <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/rn5t618_wdt.c +1
-0@@ -191,3 +191,4 @@ module_platform_driver(rn5t618_wdt_driver);MODULE_AUTHOR ("Beniamino Galvani <[email protected]>" );MODULE_DESCRIPTION ("RN5T618 watchdog driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/rza_wdt.c +1
-0@@ -245,3 +245,4 @@ module_platform_driver(rza_wdt_driver);MODULE_DESCRIPTION ("Renesas RZ/A WDT Driver" );MODULE_AUTHOR ("Chris Brandt <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/s3c2410_wdt.c +1
-0@@ -739,3 +739,4 @@ module_platform_driver(s3c2410wdt_driver);MODULE_AUTHOR ("Ben Dooks <[email protected]>, Dimitry Andric <[email protected]>" );MODULE_DESCRIPTION ("S3C2410 Watchdog Device Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/sama5d4_wdt.c +1
-0@@ -321,3 +321,4 @@ module_platform_driver(sama5d4_wdt_driver);MODULE_AUTHOR ("Atmel Corporation" );MODULE_DESCRIPTION ("Atmel SAMA5D4 Watchdog Timer driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/sirfsoc_wdt.c +1
-0@@ -213,4 +213,5 @@ module_platform_driver(sirfsoc_wdt_driver);MODULE_DESCRIPTION ("SiRF SoC watchdog driver" );MODULE_AUTHOR ("Xianglong Du <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:sirfsoc-wdt" );drivers/watchdog/softdog.c +1
-0@@ -165,3 +165,4 @@ module_exit(softdog_exit);MODULE_AUTHOR ("Alan Cox" );MODULE_DESCRIPTION ("Software Watchdog Device Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/sp5100_tco.c +1
-0@@ -486,3 +486,4 @@ module_exit(sp5100_tco_exit);MODULE_AUTHOR ("Priyanka Gupta" );MODULE_DESCRIPTION ("TCO timer driver for SP5100/SB800 chipset" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/sprd_wdt.c +1
-0@@ -384,3 +384,4 @@ module_platform_driver(sprd_watchdog_driver);MODULE_AUTHOR ("Eric Long <[email protected]>" );MODULE_DESCRIPTION ("Spreadtrum Watchdog Timer Controller Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/st_lpc_wdt.c +1
-0@@ -305,3 +305,4 @@ module_platform_driver(st_wdog_driver);MODULE_AUTHOR ("David Paris <[email protected]>" );MODULE_DESCRIPTION ("ST LPC Watchdog Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/stmp3xxx_rtc_wdt.c +1
-0@@ -150,4 +150,5 @@ module_platform_driver(stmp3xxx_wdt_driver);MODULE_DESCRIPTION ("STMP3XXX RTC Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Wolfram Sang <[email protected]>" );drivers/watchdog/stpmic1_wdt.c +1
-0@@ -138,3 +138,4 @@ module_platform_driver(stpmic1_wdt_driver);MODULE_DESCRIPTION ("Watchdog driver for STPMIC1 device" );MODULE_AUTHOR ("Pascal Paillet <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/sunxi_wdt.c +1
-0@@ -289,6 +289,7 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started " "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Carlo Caione <[email protected]>" );MODULE_AUTHOR ("Henrik Nordstrom <[email protected]>" );MODULE_DESCRIPTION ("sunxi WatchDog Timer Driver" );drivers/watchdog/tangox_wdt.c +1
-0@@ -207,3 +207,4 @@ module_platform_driver(tangox_wdt_driver);MODULE_AUTHOR ("Mans Rullgard <[email protected]>" );MODULE_DESCRIPTION ("SMP86xx/SMP87xx Watchdog driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/tegra_wdt.c +1
-0@@ -276,3 +276,4 @@ module_platform_driver(tegra_wdt_driver);MODULE_AUTHOR ("NVIDIA Corporation" );MODULE_DESCRIPTION ("Tegra Watchdog Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/tqmx86_wdt.c +1
-0@@ -124,3 +124,4 @@ MODULE_AUTHOR("Andrew Lunn <[email protected]>");MODULE_DESCRIPTION ("TQMx86 Watchdog" );MODULE_ALIAS ("platform:tqmx86-wdt" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/ts4800_wdt.c +1
-0@@ -200,4 +200,5 @@ module_platform_driver(ts4800_wdt_driver);MODULE_AUTHOR ("Damien Riegel <[email protected]>" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:ts4800_wdt" );drivers/watchdog/ts72xx_wdt.c +1
-0@@ -174,4 +174,5 @@ module_platform_driver(ts72xx_wdt_driver);MODULE_AUTHOR ("Mika Westerberg <[email protected]>" );MODULE_DESCRIPTION ("TS-72xx SBC Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:ts72xx-wdt" );drivers/watchdog/twl4030_wdt.c +1
-0@@ -123,5 +123,6 @@ module_platform_driver(twl4030_wdt_driver);MODULE_AUTHOR ("Nokia Corporation" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:twl4030_wdt" );drivers/watchdog/uniphier_wdt.c +1
-0@@ -255,3 +255,4 @@ MODULE_PARM_DESC(nowayout,MODULE_AUTHOR ("Keiji Hayashibara <[email protected]>" );MODULE_DESCRIPTION ("UniPhier Watchdog Device Driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/via_wdt.c +1
-0@@ -259,3 +259,4 @@ module_pci_driver(wdt_driver);MODULE_AUTHOR ("Marc Vertes" );MODULE_DESCRIPTION ("Driver for watchdog timer on VIA chipset" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/w83627hf_wdt.c +1
-0@@ -528,5 +528,6 @@ module_init(wdt_init);module_exit (wdt_exit);MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_AUTHOR ("Pádraig Brady <[email protected]>" );MODULE_DESCRIPTION ("w83627hf/thf WDT driver" );drivers/watchdog/watchdog_core.c +5
-5@@ -145,7 +145,7 @@ int watchdog_init_timeout(struct watchdog_device *wdd,return ret; } -EXPORT_SYMBOL_GPL (watchdog_init_timeout); +EXPORT_SYMBOL_NS_GPL (watchdog_init_timeout,WATCHDOG_CORE );static int watchdog_restart_notifier (struct notifier_block *nb,unsigned long action,void *data)@@ -180,7 +180,7 @@ void watchdog_set_restart_priority(struct watchdog_device *wdd, int priority) { wdd->restart_nb.priority = priority; } -EXPORT_SYMBOL_GPL (watchdog_set_restart_priority); +EXPORT_SYMBOL_NS_GPL (watchdog_set_restart_priority,WATCHDOG_CORE );static int __watchdog_register_device (struct watchdog_device *wdd) {@@ -279,7 +279,7 @@ int watchdog_register_device(struct watchdog_device *wdd)return ret; } -EXPORT_SYMBOL_GPL (watchdog_register_device); +EXPORT_SYMBOL_NS_GPL (watchdog_register_device,WATCHDOG_CORE );static void __watchdog_unregister_device (struct watchdog_device *wdd) {@@ -311,7 +311,7 @@ void watchdog_unregister_device(struct watchdog_device *wdd)mutex_unlock (&wtd_deferred_reg_mutex); } -EXPORT_SYMBOL_GPL (watchdog_unregister_device); +EXPORT_SYMBOL_NS_GPL (watchdog_unregister_device,WATCHDOG_CORE );static void devm_watchdog_unregister_device (struct device *dev,void *res) {@@ -348,7 +348,7 @@ int devm_watchdog_register_device(struct device *dev,return ret; } -EXPORT_SYMBOL_GPL (devm_watchdog_register_device); +EXPORT_SYMBOL_NS_GPL (devm_watchdog_register_device,WATCHDOG_CORE );static int __init watchdog_deferred_registration (void ) {drivers/watchdog/wdat_wdt.c +1
-0@@ -523,4 +523,5 @@ module_platform_driver(wdat_wdt_driver);MODULE_AUTHOR ("Mika Westerberg <[email protected]>" );MODULE_DESCRIPTION ("ACPI Hardware Watchdog (WDAT) driver" );MODULE_LICENSE ("GPL v2" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:wdat_wdt" );drivers/watchdog/wm831x_wdt.c +1
-0@@ -282,4 +282,5 @@ module_platform_driver(wm831x_wdt_driver);MODULE_AUTHOR ("Mark Brown" );MODULE_DESCRIPTION ("WM831x Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:wm831x-watchdog" );drivers/watchdog/wm8350_wdt.c +1
-0@@ -175,4 +175,5 @@ module_platform_driver(wm8350_wdt_driver);MODULE_AUTHOR ("Mark Brown" );MODULE_DESCRIPTION ("WM8350 Watchdog" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );MODULE_ALIAS ("platform:wm8350-wdt" );drivers/watchdog/xen_wdt.c +1
-0@@ -206,3 +206,4 @@ module_exit(xen_wdt_cleanup_module);MODULE_AUTHOR ("Jan Beulich <[email protected]>" );MODULE_DESCRIPTION ("Xen WatchDog Timer Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );drivers/watchdog/ziirave_wdt.c +1
-0@@ -751,3 +751,4 @@ module_i2c_driver(ziirave_wdt_driver);MODULE_AUTHOR ("Martyn Welch <[email protected]" );MODULE_DESCRIPTION ("Zodiac Aerospace RAVE Switch Watchdog Processor Driver" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (WATCHDOG_CORE );Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
Quoted 26 lines · Guenter Roeck
Quoted 24 lines · Matthias Maennich
Modules using symbols from the
WATCHDOG_COREnamespace are required to explicitly import the namespace. This patch was generated with the following steps and serves as a reference to use the symbol namespace feature:1) Use EXPORT_SYMBOL_NS* macros instead of EXPORT_SYMBOL* for symbols in
watchdog_core.c
2) make (see warnings during modpost about missing imports)
3) make nsdepsI used 'allmodconfig' for the above steps to ensure all occurrences are patched.
Defining
DEFAULT_SYMBOL_NAMESPACEin theMakefileis not trivial in this case as not onlywatchdog_coreis defined indrivers/watchdog/Makefile. Hence this patch uses the variant of using the EXPORT_SYMBOL_NS* macros to export into a different namespace.An alternative to this patch would be a single definition line before any use of EXPORT_SYMBOL*:
#defineDEFAULT_SYMBOL_NAMESPACEWATCHDOG_COREThis patch serves as a reference on how to use the symbol namespaces.
Quoted 7 lines
Quoted 2 lines
Reviewed-by Greg Kroah-Hartman <[email protected]>Signed-off-by Matthias Maennich <[email protected]>As mentioned before, I am opposed to this set of changes. I don't see the point of restricting the use of exported symbols in
WATCHDOG_CORE.Guenter
I agree.
I do not like this patch set either.
Anyway, the last two patches (usb-stroage, watchdog) are useful to demonstrate
that this has a bad taste.
--
Best Regards
Masahiro Yamada
Guenter Roeck
maintainerRe: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
Quoted 33 lines · Masahiro Yamada
Quoted 32 lines · Guenter Roeck
Quoted 18 lines · Matthias Maennich
Modules using symbols from the
WATCHDOG_COREnamespace are required to explicitly import the namespace. This patch was generated with the following steps and serves as a reference to use the symbol namespace feature:1) Use EXPORT_SYMBOL_NS* macros instead of EXPORT_SYMBOL* for symbols in
watchdog_core.c
2) make (see warnings during modpost about missing imports)
3) make nsdepsI used 'allmodconfig' for the above steps to ensure all occurrences are patched.
Defining
DEFAULT_SYMBOL_NAMESPACEin theMakefileis not trivial in this case as not onlywatchdog_coreis defined indrivers/watchdog/Makefile. Hence this patch uses the variant of using the EXPORT_SYMBOL_NS* macros to export into a different namespace.Quoted 8 lines
An alternative to this patch would be a single definition line before any use of EXPORT_SYMBOL*:
#defineDEFAULT_SYMBOL_NAMESPACEWATCHDOG_COREThis patch serves as a reference on how to use the symbol namespaces.
Reviewed-by Greg Kroah-Hartman <[email protected]>Signed-off-by Matthias Maennich <[email protected]>As mentioned before, I am opposed to this set of changes. I don't see the point of restricting the use of exported symbols in
WATCHDOG_CORE.
Quoted 7 lines
Quoted 1 line
Guenter
I agree.
I do not like this patch set either.
Note that I don't object to the patch set in general. There may be symbols which only need be exported in the context of a single subsystem or even driver (if a driver consists of more than one module). For example, a mfd driver may export symbols which should only be called by its client drivers. In such a situation, it may well be beneficial to limit the use of exported symbols.
I am not sure what good that does in practice (if I understand correctly, a driver only has to declare that it wants to use a restricted use symbol if it wants to use it), but that is a different question.
Guenter
Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
Quoted 7 lines · Guenter Roeck
Note that I don't object to the patch set in general. There may be symbols which only need be exported in the context of a single subsystem or even driver (if a driver consists of more than one module). For example, a mfd driver may export symbols which should only be called by its client drivers. In such a situation, it may well be beneficial to limit the use of exported symbols.
I can appreciate this benefit.
Quoted 3 lines
I am not sure what good that does in practice (if I understand correctly, a driver only has to declare that it wants to use a restricted use symbol if it wants to use it), but that is a different question.
I think this question implies that you are coming from the perspective of "security" or wanting to restrict access to the underlying functions, rather than wanting to clean-up the way symbols are handled for manageability / maintainability purposes (which is the goal, as I understand it).
HOWEVER, I have one question: If these patches are included, and someone wants to introduce a bit of code which needs to use two symbols from different namespaces but with the same name, can that be done? That is, if driver A has symbol 'foo' and driver B has symbol 'foo' (both in their respective namespaces), and driver C wants to use A.foo and B.foo, can that be supported?
Matt
Signature · 2 lines
Matthew Dharm Former Maintainer, USB Mass Storage driver for Linux
Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
+++ Matthew Dharm [04/09/19 09:16 -0700]:
Quoted 21 lines · Guenter Roeck
Quoted 7 lines
Note that I don't object to the patch set in general. There may be symbols which only need be exported in the context of a single subsystem or even driver (if a driver consists of more than one module). For example, a mfd driver may export symbols which should only be called by its client drivers. In such a situation, it may well be beneficial to limit the use of exported symbols.
I can appreciate this benefit.
Quoted 3 lines
I am not sure what good that does in practice (if I understand correctly, a driver only has to declare that it wants to use a restricted use symbol if it wants to use it), but that is a different question.
I think this question implies that you are coming from the perspective of "security" or wanting to restrict access to the underlying functions, rather than wanting to clean-up the way symbols are handled for manageability / maintainability purposes (which is the goal, as I understand it).
Quoted 6 lines
HOWEVER, I have one question: If these patches are included, and someone wants to introduce a bit of code which needs to use two symbols from different namespaces but with the same name, can that be done? That is, if driver A has symbol 'foo' and driver B has symbol 'foo' (both in their respective namespaces), and driver C wants to use A.foo and B.foo, can that be supported?
As of now, we currently don't support this - modpost will warn if a symbol is exported more than once (across modules + vmlinux), and the module loader currently assumes exported symbol names are unique. Do you have a concrete use case? If there is a strong need for this, I don't think it'd be too hard to implement.
Thanks,
Jessica
Arnd Bergmann
maintainerRe: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
Quoted 10 lines · Jessica Yu
+++ Matthew Dharm [04/09/19 09:16 -0700]:
Quoted 8 lines · Guenter Roeck
HOWEVER, I have one question: If these patches are included, and someone wants to introduce a bit of code which needs to use two symbols from different namespaces but with the same name, can that be done? That is, if driver A has symbol 'foo' and driver B has symbol 'foo' (both in their respective namespaces), and driver C wants to use A.foo and B.foo, can that be supported?
Quoted 5 lines
As of now, we currently don't support this - modpost will warn if a symbol is exported more than once (across modules + vmlinux), and the module loader currently assumes exported symbol names are unique. Do you have a concrete use case? If there is a strong need for this, I don't think it'd be too hard to implement.
I think what would prevent this from working in general is that having two modules with the same exported symbol in different namespaces won't link if you try to build both modules into the kernel itself.
Arnd
Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
+++ Arnd Bergmann [05/09/19 12:52 +0200]:
Quoted 17 lines · Jessica Yu
Quoted 10 lines
+++ Matthew Dharm [04/09/19 09:16 -0700]:
Quoted 8 lines · Guenter Roeck
HOWEVER, I have one question: If these patches are included, and someone wants to introduce a bit of code which needs to use two symbols from different namespaces but with the same name, can that be done? That is, if driver A has symbol 'foo' and driver B has symbol 'foo' (both in their respective namespaces), and driver C wants to use A.foo and B.foo, can that be supported?
Quoted 5 lines
As of now, we currently don't support this - modpost will warn if a symbol is exported more than once (across modules + vmlinux), and the module loader currently assumes exported symbol names are unique. Do you have a concrete use case? If there is a strong need for this, I don't think it'd be too hard to implement.
Quoted 5 lines
I think what would prevent this from working in general is that having two modules with the same exported symbol in different namespaces won't link if you try to build both modules into the kernel itself.
Arnd
Ah yeah, you are right. I only tried building an identically named exported symbol in a module and in the kernel, and there I got away with a modpost warning. But this breaks when building the module into the kernel, so I guess this is out of the question.
Thanks,
Jessica
Re: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
Quoted 25 lines · Jessica Yu
+++ Arnd Bergmann [05/09/19 12:52 +0200]:
Quoted 17 lines · Jessica Yu
Quoted 10 lines
+++ Matthew Dharm [04/09/19 09:16 -0700]:
Quoted 8 lines · Guenter Roeck
HOWEVER, I have one question: If these patches are included, and someone wants to introduce a bit of code which needs to use two symbols from different namespaces but with the same name, can that be done? That is, if driver A has symbol 'foo' and driver B has symbol 'foo' (both in their respective namespaces), and driver C wants to use A.foo and B.foo, can that be supported?
Quoted 5 lines
As of now, we currently don't support this - modpost will warn if a symbol is exported more than once (across modules + vmlinux), and the module loader currently assumes exported symbol names are unique. Do you have a concrete use case? If there is a strong need for this, I don't think it'd be too hard to implement.
Quoted 5 lines
I think what would prevent this from working in general is that having two modules with the same exported symbol in different namespaces won't link if you try to build both modules into the kernel itself.
Arnd
Quoted 9 lines
Ah yeah, you are right. I only tried building an identically named exported symbol in a module and in the kernel, and there I got away with a modpost warning. But this breaks when building the module into the kernel, so I guess this is out of the question.
Thanks,
Jessica
The cover letter starts with
"As of Linux 5.3-rc7, there are 31207 [1] exported symbols in the kernel".
Whether or not we apply this patch set, we will have to carefully maintain them so that 31207 symbols are unique, anyway. (And, we can do this with allmodconfig + modpost)
So, what is the point of the namespace, where it does not loosen the scope of uniqueness?
--
Best Regards
Masahiro Yamada
Greg Kroah-Hartman
maintainerRe: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
Quoted 40 lines · Masahiro Yamada
Quoted 25 lines · Jessica Yu
+++ Arnd Bergmann [05/09/19 12:52 +0200]:
Quoted 17 lines · Jessica Yu
Quoted 10 lines
+++ Matthew Dharm [04/09/19 09:16 -0700]:
Quoted 8 lines · Guenter Roeck
HOWEVER, I have one question: If these patches are included, and someone wants to introduce a bit of code which needs to use two symbols from different namespaces but with the same name, can that be done? That is, if driver A has symbol 'foo' and driver B has symbol 'foo' (both in their respective namespaces), and driver C wants to use A.foo and B.foo, can that be supported?
Quoted 5 lines
As of now, we currently don't support this - modpost will warn if a symbol is exported more than once (across modules + vmlinux), and the module loader currently assumes exported symbol names are unique. Do you have a concrete use case? If there is a strong need for this, I don't think it'd be too hard to implement.
Quoted 5 lines
I think what would prevent this from working in general is that having two modules with the same exported symbol in different namespaces won't link if you try to build both modules into the kernel itself.
Arnd
Quoted 9 lines
Ah yeah, you are right. I only tried building an identically named exported symbol in a module and in the kernel, and there I got away with a modpost warning. But this breaks when building the module into the kernel, so I guess this is out of the question.
Thanks,
Jessica
The cover letter starts with
"As of Linux 5.3-rc7, there are 31207 [1] exported symbols in the kernel".
Quoted 7 lines
Whether or not we apply this patch set, we will have to carefully maintain them so that 31207 symbols are unique, anyway. (And, we can do this with allmodconfig + modpost)
So, what is the point of the namespace, where it does not loosen the scope of uniqueness?
It does not "loosen" anything. The problem is, we have 31207 exported symbols and no one has any idea how they are "clustered" :)
Ideally we would have separate namespaces where we could "keep" others from accessing symbols that are required to be global, but we do not want anyone else to use them. But we have C, and we need to live with that.
This is the "next best thing". This provides a namespace and a marking by the user of that exported symbol that they really do know what they are doing.
The USB storage exports are a concrete example of this in this patchset. Those symbols are to only be used by other USB storage drivers, and they are marked that way here.
This also gives us the ability to start to actually understand what our different exported symbols are for. Right now the USB core exports a ton of stuff, but who is expected to use what? Right now any USB driver can use any of those functions and no one notices. After this patchset is merged, I will start to "carve up" the USB exports into different "namespaces". One example will be the functions only for use by USB host controller drivers. Then if someone submits a new driver that says "use the USB host controller driver namespace", and that driver is _not_ a USB host controller driver, it's a huge red flag that something really isn't correct here.
Some other USB functions will probably get marked "USB core only" or some such thing, and then to use them you have to say you are importing from the "usb core only" which again, is a huge flag that you are doing something wrong.
So on it's own, this patchset doesn't do much. But it gives us the building blocks on which to start to make sense of those 31000+ different exported symbols.
As an aside, this is something that I know I and others have been wanting to see happen for 10+ years now, and I'm very happy to see it show up in a workable form as we have known this is a issue for a very long time.
Hope this helps explain things better,
greg k-h
Matthias Maennich
maintainerRe: [usb-storage] Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
In reply to Jessica YuQuoted 21 lines · Jessica Yu
+++ Matthew Dharm [04/09/19 09:16 -0700]:
Quoted 20 lines · Guenter Roeck
Quoted 7 lines
Note that I don't object to the patch set in general. There may be symbols which only need be exported in the context of a single subsystem or even driver (if a driver consists of more than one module). For example, a mfd driver may export symbols which should only be called by its client drivers. In such a situation, it may well be beneficial to limit the use of exported symbols.
I can appreciate this benefit.
Quoted 3 lines
I am not sure what good that does in practice (if I understand correctly, a driver only has to declare that it wants to use a restricted use symbol if it wants to use it), but that is a different question.
I think this question implies that you are coming from the perspective of "security" or wanting to restrict access to the underlying functions, rather than wanting to clean-up the way symbols are handled for manageability / maintainability purposes (which is the goal, as I understand it).
The goal of this patch set is to introduce structure into the exported surface that goes beyond naming conventions like 'usb_*'. So, it is rather about maintainability then security. In particular, creating the visibility of which parts of the kernel use which other parts, might help to find cases where suboptimal choices were made. Maybe already during development/review.
As Guenter correctly noted, a module is able to declare that it wants to use a namespace. One idea that came up earlier was to maybe restrict the namespaces that can actually be imported by modules. But I would see anything in that direction as beyond the scope of this series.
A nice side effect of having to declare the usage is that it shows up in modinfo and module users can reason about how the module interacts with the rest of the kernel.
Quoted 7 lines
Quoted 6 lines
HOWEVER, I have one question: If these patches are included, and someone wants to introduce a bit of code which needs to use two symbols from different namespaces but with the same name, can that be done? That is, if driver A has symbol 'foo' and driver B has symbol 'foo' (both in their respective namespaces), and driver C wants to use A.foo and B.foo, can that be supported?
Quoted 5 lines
As of now, we currently don't support this - modpost will warn if a symbol is exported more than once (across modules + vmlinux), and the module loader currently assumes exported symbol names are unique. Do you have a concrete use case? If there is a strong need for this, I don't think it'd be too hard to implement.
The implementation does not change the fact that symbol names need to be unique. As Arnd just mentioned in the other thread: the linker will already fail if two builtin symbols use the same name. It is rather a tag attached to the symbol.
Cheers,
Matthias
Re: [PATCH v4 00/12] Symbol Namespaces
In reply to Matthias MaennichQuoted 23 lines · Matthias Maennich
As of Linux 5.3-rc7, there are 31207 [1] exported symbols in the kernel. That is a growth of roughly 1000 symbols since 4.17 (30206 [2]). There seems to be some consensus amongst kernel devs that the export surface is too large, and hard to reason about.
Generally, these symbols fall in one of these categories:
1) Symbols actually meant for drivers
2) Symbols that are only exported because functionality is split over multiple modules, yet they really shouldn't be used by modules outside of their own subsystem
3) Symbols really only meant for in-tree useWhen module developers try to upstream their code, it regularly turns out that they are using exported symbols that they really shouldn't be using. This problem is even bigger for drivers that are currently out-of-tree, which may be using many symbols that they shouldn't be using, and that break when those symbols are removed or modified.
This patch allows subsystem maintainers to partition their exported symbols into separate namespaces, and module authors to import such namespaces only when needed.
Quoted 5 lines
This allows subsystem maintainers to more easily limit availability of these namespaced symbols to other parts of the kernel. It can also be used to partition the set of exported symbols for documentation purposes; for example, a set of symbols that is really only used for debugging could be in a "
SUBSYSTEM_DEBUG" namespace.
Why is the namespace helpful to limit the availability of symbols? External modules would add whatever EXPORT_SYMBOL_NS() needed to use the symbols.
Nothing would change except that it would increase the code size.
If we introduce the namespace, do symbols no longer need to be globally unique?
Theoretically, we could do this:
EXPORT_SYMBOL_NS(foo, SUBSYSTEM_A); (for Subsystem-A)EXPORT_SYMBOL_NS(foo, SUBSYSTEM_B); (for Subsystem-B)
But, I do not see benefit to do so.
We usually prefix symbol names with the sybsystem names (usb_ ... , watchdog_ ...).
By ensuring the symbol uniqueness,
it is really clear which functions are called.
You can easily grep the source code.
Editors can follow the code with tag files.
Adding namespace just introduces extra complexity.
Thanks.
Quoted 223 lines
The series contains two RFC patches that do not need to be merged along with the rest of the series, but they serve as a reference for using the symbol namespaces. Especially, the watchdog subsystem might not be affected by the issues addressed by Symbol Namespaces. I left the patch in for reference anyway for demonstration purposes.
I continued the work mainly done by Martijn Coenen.
Changes in v2:
- Rather than adding and evaluating separate sections__knsimport_NS, use modinfo tags to declare the namespaces a module introduces. Adjust modpost and the module loader accordingly.
- Also add support for reading multiple modinfo values for the same tag to allow list-like access to modinfo tags.
- The macros inexport.hhave been cleaned up to avoid redundancy in the macro parameters (ns, nspost, nspost2).
- The introduction of relative references in the ksymtab entries caused a rework of the macros to accommodate that configuration as well.
- Alignment ofkernel_symbolin the ksymtab needed to be fixed to allow growing thekernel_symbolstruct.
- Modpost does now also append the namespace suffix to the symbol entries in Module.symvers.
- The configuration optionMODULE_ALLOW_MISSING_NAMESPACE_IMPORTSallows relaxing the enforcement of properly declared namespace imports at module loading time.
- Symbols can be collectively exported into a namespace by definingDEFAULT_SYMBOL_NAMESPACEin the correspondingMakefile.
- The requirement for a very recent coccinelle spatch has been lifted by simplifying the script.
- nsdeps does now ensuresMODULE_IMPORT_NSstatements are sorted when patching the module source files.
- Some minor bugs have been addressed in nsdeps to allow it to work with modules that have more than one source file.
- The RFC for the usb-storage symbols has been simplified by using DEFAULT_SYMBOL_NAMESPACE=USB_STORAGE rather than explicitly exporting each and every symbol into that new namespace.Changes in v3:
- Reword the documentation for theMODULE_ALLOW_MISSING_NAMESPACE_IMPORTSoption for clarification.
- Fix printed required version of spatch in coccinelle script.
- Adopt kbuild changes for modpost: .mod files are no longer generated in .tmp_versions. Similarely, generate the .ns_deps files in the tree along with the .mod files. Also, nsdeps now uses modules.order as source for the list modules to consider.
- Add an RFC patch to introduce the namespaceWATCHDOG_COREfor symbols exported inwatchdog_core.c.Changes in v4:
-scripts/nsdeps:
- exit on first error
- support out-of-tree builds O=...
-scripts/mod/modpost: make the namespace a separate field when exporting to Module.symvers (rather than symbol.NS)
-scripts/export_report.pl: update for new Module.symvers format
-include/linux/export.h: fixed style nits
-kernel/module.c: ensure namespaces are imported before taking a reference to the owner module
- Documentation: document the Symbol Namespace feature and update references to Module.symvers and EXPORT_SYMBOL*This patch series was developed against v5.3-rc7.
[1] git grep "^EXPORT_SYMBOL\w*(" v5.3-rc7 | wc -l
[2] git grep "^EXPORT_SYMBOL\w*(" v4.17 | wc -lMatthias Maennich (12):
module: support reading multiple values per modinfo tag
export: explicitly align structkernel_symbol
module: add support for symbol namespaces.
modpost: add support for symbol namespaces
module: add config optionMODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
export: allow definition default namespaces in Makefiles or sources
modpost: add support for generating namespace dependencies
scripts: Coccinelle script for namespace dependencies.
docs: Add documentation for Symbol Namespaces
usb-storage: remove single-use define for debugging
RFC: usb-storage: export symbols inUSB_STORAGEnamespace
RFC: watchdog: export core symbols inWATCHDOG_COREnamespace.gitignore | 1 + Documentation/kbuild/modules.rst | 7 +- Documentation/kbuild/namespaces.rst | 154 ++++++++++++++++++++ Documentation/kernel-hacking/hacking.rst | 18 +++ MAINTAINERS | 5 + Makefile | 14 +- arch/m68k/include/asm/export.h | 1 - drivers/hwmon/ftsteutates.c | 1 + drivers/hwmon/sch56xx-common.c | 1 + drivers/rtc/rtc-abx80x.c | 1 + drivers/usb/storage/Makefile | 2 + drivers/usb/storage/alauda.c | 1 + drivers/usb/storage/cypress_atacb.c | 1 + drivers/usb/storage/datafab.c | 1 + drivers/usb/storage/debug.h | 2 - drivers/usb/storage/ene_ub6250.c | 1 + drivers/usb/storage/freecom.c | 1 + drivers/usb/storage/isd200.c | 1 + drivers/usb/storage/jumpshot.c | 1 + drivers/usb/storage/karma.c | 1 + drivers/usb/storage/onetouch.c | 1 + drivers/usb/storage/realtek_cr.c | 1 + drivers/usb/storage/scsiglue.c | 2 +- drivers/usb/storage/sddr09.c | 1 + drivers/usb/storage/sddr55.c | 1 + drivers/usb/storage/shuttle_usbat.c | 1 + drivers/usb/storage/uas.c | 1 + drivers/watchdog/armada_37xx_wdt.c | 1 + drivers/watchdog/asm9260_wdt.c | 1 + drivers/watchdog/aspeed_wdt.c | 1 + drivers/watchdog/at91sam9_wdt.c | 1 + drivers/watchdog/atlas7_wdt.c | 1 + drivers/watchdog/bcm2835_wdt.c | 1 + drivers/watchdog/bcm47xx_wdt.c | 1 + drivers/watchdog/bcm7038_wdt.c | 1 + drivers/watchdog/bcm_kona_wdt.c | 1 + drivers/watchdog/bd70528_wdt.c | 1 + drivers/watchdog/cadence_wdt.c | 1 + drivers/watchdog/da9052_wdt.c | 1 + drivers/watchdog/da9055_wdt.c | 1 + drivers/watchdog/da9062_wdt.c | 1 + drivers/watchdog/da9063_wdt.c | 1 + drivers/watchdog/davinci_wdt.c | 1 + drivers/watchdog/digicolor_wdt.c | 1 + drivers/watchdog/dw_wdt.c | 1 + drivers/watchdog/ebc-c384_wdt.c | 1 + drivers/watchdog/ep93xx_wdt.c | 1 + drivers/watchdog/ftwdt010_wdt.c | 1 + drivers/watchdog/gpio_wdt.c | 1 + drivers/watchdog/hpwdt.c | 1 + drivers/watchdog/i6300esb.c | 1 + drivers/watchdog/iTCO_wdt.c | 1 + drivers/watchdog/ie6xx_wdt.c | 1 + drivers/watchdog/imgpdc_wdt.c | 1 + drivers/watchdog/imx2_wdt.c | 1 + drivers/watchdog/intel-mid_wdt.c | 1 + drivers/watchdog/it87_wdt.c | 1 + drivers/watchdog/kempld_wdt.c | 1 + drivers/watchdog/lpc18xx_wdt.c | 1 + drivers/watchdog/max63xx_wdt.c | 1 + drivers/watchdog/max77620_wdt.c | 1 + drivers/watchdog/mei_wdt.c | 1 + drivers/watchdog/mena21_wdt.c | 1 + drivers/watchdog/menf21bmc_wdt.c | 1 + drivers/watchdog/menz69_wdt.c | 1 + drivers/watchdog/meson_gxbb_wdt.c | 1 + drivers/watchdog/meson_wdt.c | 1 + drivers/watchdog/mlx_wdt.c | 1 + drivers/watchdog/moxart_wdt.c | 1 + drivers/watchdog/mtk_wdt.c | 1 + drivers/watchdog/ni903x_wdt.c | 1 + drivers/watchdog/nic7018_wdt.c | 1 + drivers/watchdog/npcm_wdt.c | 1 + drivers/watchdog/of_xilinx_wdt.c | 1 + drivers/watchdog/omap_wdt.c | 1 + drivers/watchdog/pm8916_wdt.c | 1 + drivers/watchdog/qcom-wdt.c | 1 + drivers/watchdog/rave-sp-wdt.c | 1 + drivers/watchdog/renesas_wdt.c | 1 + drivers/watchdog/retu_wdt.c | 1 + drivers/watchdog/rn5t618_wdt.c | 1 + drivers/watchdog/rza_wdt.c | 1 + drivers/watchdog/s3c2410_wdt.c | 1 + drivers/watchdog/sama5d4_wdt.c | 1 + drivers/watchdog/sirfsoc_wdt.c | 1 + drivers/watchdog/softdog.c | 1 + drivers/watchdog/sp5100_tco.c | 1 + drivers/watchdog/sprd_wdt.c | 1 + drivers/watchdog/st_lpc_wdt.c | 1 + drivers/watchdog/stmp3xxx_rtc_wdt.c | 1 + drivers/watchdog/stpmic1_wdt.c | 1 + drivers/watchdog/sunxi_wdt.c | 1 + drivers/watchdog/tangox_wdt.c | 1 + drivers/watchdog/tegra_wdt.c | 1 + drivers/watchdog/tqmx86_wdt.c | 1 + drivers/watchdog/ts4800_wdt.c | 1 + drivers/watchdog/ts72xx_wdt.c | 1 + drivers/watchdog/twl4030_wdt.c | 1 + drivers/watchdog/uniphier_wdt.c | 1 + drivers/watchdog/via_wdt.c | 1 + drivers/watchdog/w83627hf_wdt.c | 1 + drivers/watchdog/watchdog_core.c | 10 +- drivers/watchdog/wdat_wdt.c | 1 + drivers/watchdog/wm831x_wdt.c | 1 + drivers/watchdog/wm8350_wdt.c | 1 + drivers/watchdog/xen_wdt.c | 1 + drivers/watchdog/ziirave_wdt.c | 1 + include/asm-generic/export.h | 14 +- include/linux/export.h | 98 +++++++++++-- include/linux/module.h | 2 + init/Kconfig | 13 ++ kernel/module.c | 67 ++++++++- scripts/Makefile.modpost | 4 +- scripts/coccinelle/misc/add_namespace.cocci | 23 +++ scripts/export_report.pl | 2 +- scripts/mod/modpost.c | 150 ++++++++++++++++--- scripts/mod/modpost.h | 9 ++ scripts/nsdeps | 60 ++++++++ 118 files changed, 697 insertions(+), 57 deletions(-) create mode 100644 Documentation/kbuild/namespaces.rst create mode 100644 scripts/coccinelle/misc/add_namespace.cocci create mode 100644 scripts/nsdeps--
2.23.0.187.g17f5b7556c-goog
Signature · 2 lines
Best Regards Masahiro Yamada
Matthias Maennich
maintainerv5 cover Symbol Namespaces
In reply to Martijn CoenenAs of Linux 5.3-rc7, there are 31207 [1] exported symbols in the kernel. That is a growth of roughly 1000 symbols since 4.17 (30206 [2]). There seems to be some consensus amongst kernel devs that the export surface is too large, and hard to reason about.
Generally, these symbols fall in one of these categories:
1) Symbols actually meant for drivers
2) Symbols that are only exported because functionality is split over multiple modules, yet they really shouldn't be used by modules outside of their own subsystem
3) Symbols really only meant for in-tree use
When module developers try to upstream their code, it regularly turns out that they are using exported symbols that they really shouldn't be using. This problem is even bigger for drivers that are currently out-of-tree, which may be using many symbols that they shouldn't be using, and that break when those symbols are removed or modified.
This patch allows subsystem maintainers to partition their exported symbols into separate namespaces, and module authors to import such namespaces only when needed.
This allows subsystem maintainers to more easily limit availability of these namespaced symbols to other parts of the kernel. It can also be used to partition the set of exported symbols for documentation purposes; for example, a set of symbols that is really only used for debugging could be in a "SUBSYSTEM_DEBUG" namespace.
I continued the work mainly done by Martijn Coenen.
Changes in v2:
- Rather than adding and evaluating separate sections __knsimport_NS, use modinfo tags to declare the namespaces a module introduces. Adjust modpost and the module loader accordingly.
- Also add support for reading multiple modinfo values for the same tag to allow list-like access to modinfo tags.
- The macros in export.h have been cleaned up to avoid redundancy in the macro parameters (ns, nspost, nspost2).
- The introduction of relative references in the ksymtab entries caused a rework of the macros to accommodate that configuration as well.
- Alignment of kernel_symbol in the ksymtab needed to be fixed to allow growing the kernel_symbol struct.
- Modpost does now also append the namespace suffix to the symbol entries in Module.symvers.
- The configuration option MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS allows relaxing the enforcement of properly declared namespace imports at module loading time.
- Symbols can be collectively exported into a namespace by defining DEFAULT_SYMBOL_NAMESPACE in the corresponding Makefile.
- The requirement for a very recent coccinelle spatch has been lifted by simplifying the script.
- nsdeps does now ensures MODULE_IMPORT_NS statements are sorted when patching the module source files.
- Some minor bugs have been addressed in nsdeps to allow it to work with modules that have more than one source file.
- The RFC for the usb-storage symbols has been simplified by using DEFAULT_SYMBOL_NAMESPACE=USB_STORAGE rather than explicitly exporting each and every symbol into that new namespace.
Changes in v3:
- Reword the documentation for the MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS option for clarification.
- Fix printed required version of spatch in coccinelle script.
- Adopt kbuild changes for modpost: .mod files are no longer generated in .tmp_versions. Similarely, generate the .ns_deps files in the tree along with the .mod files. Also, nsdeps now uses modules.order as source for the list modules to consider.
- Add an RFC patch to introduce the namespace WATCHDOG_CORE for symbols exported in watchdog_core.c.
Changes in v4:
- scripts/nsdeps:
- exit on first error
- support out-of-tree builds O=...
- scripts/export_report.pl: update for new Module.symvers format
- scripts/mod/modpost: make the namespace a separate field when exporting to Module.symvers (rather than symbol.NS)
- include/linux/export.h: fixed style nits
- kernel/module.c: ensure namespaces are imported before taking a reference to the owner module
- Documentation: document the Symbol Namespace feature and update references to Module.symvers and EXPORT_SYMBOL*
Changes in v5:
- Makefile: let 'nsdeps' depend on 'modules' to allow
make clean; make nsdeps to work
- scripts/nsdeps: drop 'exit on first error' again as it just makes more problems than it solves
- drop the watchdog RFC patch for now
This patch series was developed against v5.3-rc7.
[1] git grep "^EXPORT_SYMBOL\w*(" v5.3-rc7 | wc -l
[2] git grep "^EXPORT_SYMBOL\w*(" v4.17 | wc -l
Matthias Maennich (11):
module: support reading multiple values per modinfo tag
export: explicitly align struct kernel_symbol
module: add support for symbol namespaces.
modpost: add support for symbol namespaces
module: add config option MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
export: allow definition default namespaces in Makefiles or sources
modpost: add support for generating namespace dependencies
scripts: Coccinelle script for namespace dependencies.
docs: Add documentation for Symbol Namespaces
usb-storage: remove single-use define for debugging
usb-storage: export symbols in USB_STORAGE namespace
.gitignore | 1 + Documentation/kbuild/modules.rst | 7 +- Documentation/kbuild/namespaces.rst | 154 ++++++++++++++++++++ Documentation/kernel-hacking/hacking.rst | 18 +++ MAINTAINERS | 5 + Makefile | 14 +- arch/m68k/include/asm/export.h | 1 - drivers/usb/storage/Makefile | 2 + drivers/usb/storage/alauda.c | 1 + drivers/usb/storage/cypress_atacb.c | 1 + drivers/usb/storage/datafab.c | 1 + drivers/usb/storage/debug.h | 2 - drivers/usb/storage/ene_ub6250.c | 1 + drivers/usb/storage/freecom.c | 1 + drivers/usb/storage/isd200.c | 1 + drivers/usb/storage/jumpshot.c | 1 + drivers/usb/storage/karma.c | 1 + drivers/usb/storage/onetouch.c | 1 + drivers/usb/storage/realtek_cr.c | 1 + drivers/usb/storage/scsiglue.c | 2 +- drivers/usb/storage/sddr09.c | 1 + drivers/usb/storage/sddr55.c | 1 + drivers/usb/storage/shuttle_usbat.c | 1 + drivers/usb/storage/uas.c | 1 + include/asm-generic/export.h | 14 +- include/linux/export.h | 98 +++++++++++-- include/linux/module.h | 2 + init/Kconfig | 13 ++ kernel/module.c | 67 ++++++++- scripts/Makefile.modpost | 4 +- scripts/coccinelle/misc/add_namespace.cocci | 23 +++ scripts/export_report.pl | 2 +- scripts/mod/modpost.c | 150 ++++++++++++++++--- scripts/mod/modpost.h | 9 ++ scripts/nsdeps | 58 ++++++++ 35 files changed, 608 insertions(+), 52 deletions(-) create mode 100644 Documentation/kbuild/namespaces.rst create mode 100644 scripts/coccinelle/misc/add_namespace.cocci create mode 100644 scripts/nsdeps
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Matthias Maennich
maintainerPATCH v5 1/11 module: support reading multiple values per modinfo tag
Similar to modpost's get_next_modinfo(), introduce get_next_modinfo() in kernel/module.c to acquire any further values associated with the same modinfo tag name. That is useful for any tags that have multiple occurrences (such as 'alias'), but is in particular introduced here as part of the symbol namespaces patch series to read the (potentially) multiple namespaces a module is importing.
--- kernel/module.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
kernel/module.c +15 -2
@@ -2481,7 +2481,8 @@ static char *next_string(char *string, unsigned long *secsize)return string; } -static char *get_modinfo (struct load_info *info,const char *tag) +static char *get_next_modinfo (const struct load_info *info,const char *tag, +char *prev) {char *p;unsigned int taglen =strlen (tag);
@@ -2492,13 +2493,25 @@ static char *get_modinfo(struct load_info *info, const char *tag)* get_modinfo() calls made before rewrite_section_headers() * must use sh_offset, as sh_addr isn't set! */ -for (p = (char *)info->hdr + infosec->sh_offset; p; p =next_string (p, &size)) { +char *modinfo = (char *)info->hdr + infosec->sh_offset; + +if (prev) { + size -= prev - modinfo; + modinfo =next_string (prev, &size); + } + +for (p = modinfo; p; p =next_string (p, &size)) {if (strncmp (p, tag, taglen) ==0 && p[taglen] =='=' )return p + taglen +1 ; }return NULL ; } +static char *get_modinfo (const struct load_info *info,const char *tag) +{ +return get_next_modinfo (info, tag,NULL ); +} +static void setup_modinfo (struct module *mod,struct load_info *info) {struct module_attribute *attr;
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Matthias Maennich
maintainerPATCH v5 2/11 export: explicitly align struct kernel_symbol
In reply to Matthias MaennichThis change allows growing struct kernel_symbol without wasting bytes to alignment. It also concretized the alignment of ksymtab entries if relative references are used for ksymtab entries.
struct kernel_symbol was already implicitly being aligned to the word size, except on x86_64 and m68k, where it is aligned to 16 and 2 bytes, respectively.
As far as I can tell there is no requirement for aligning struct kernel_symbol to 16 bytes on x86_64, but gcc aligns structs to their size, and the linker aligns the custom __ksymtab sections to the largest data type contained within, so setting KSYM_ALIGN to 16 was necessary to stay consistent with the code generated for non-ASM EXPORT_SYMBOL(). Now that non-ASM EXPORT_SYMBOL() explicitly aligns to word size (8), KSYM_ALIGN is no longer necessary.
In case of relative references, the alignment has been changed accordingly to not waste space when adding new struct members.
As for m68k, struct kernel_symbol is aligned to 2 bytes even though the structure itself is 8 bytes; using a 4-byte alignment shouldn't hurt.
I manually verified the output of the __ksymtab sections didn't change on x86, x86_64, arm, arm64 and m68k. As expected, the section contents didn't change, and the ELF section alignment only changed on x86_64 and m68k. Feedback from other archs more than welcome.
--- arch/m68k/include/asm/export.h | 1 - include/asm-generic/export.h | 8 +++----- include/linux/export.h | 3 ++- 3 files changed, 5 insertions(+), 7 deletions(-)
arch/m68k/include/asm/export.h +0 -1
@@ -1,3 +1,2 @@ -#define KSYM_ALIGN 2#define KCRC_ALIGN 2#include <asm-generic/export.h>
include/asm-generic/export.h +3 -5
@@ -4,15 +4,13 @@#ifndef KSYM_FUNC #define KSYM_FUNC (x) x#endif -#ifdef CONFIG_64BIT -#ifndef KSYM_ALIGN +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS +#define KSYM_ALIGN 4 +#elif defined(CONFIG_64BIT )#define KSYM_ALIGN 8 -#endif #else -#ifndef KSYM_ALIGN #define KSYM_ALIGN 4#endif -#endif #ifndef KCRC_ALIGN #define KCRC_ALIGN 4#endif
include/linux/export.h +2 -1
@@ -52,7 +52,7 @@ extern struct module __this_module;#define __KSYMTAB_ENTRY (sym, sec) \ __ADDRESSABLE(sym) \ asm(" .section \"___ksymtab" sec "+" #sym "\", \"a\" \n" \ - " .balign 8 \n" \ + " .balign 4 \n" \ "__ksymtab_" #sym ": \n" \ " .long " #sym "- . \n" \ " .long __kstrtab_" #sym "- . \n" \
@@ -66,6 +66,7 @@ struct kernel_symbol {#define __KSYMTAB_ENTRY (sym, sec) \ static const struct kernel_symbol __ksymtab_##sym \ __attribute__((section("___ksymtab" sec "+" #sym), used)) \ + __aligned(sizeof(void *)) \ = { (unsigned long)&sym, __kstrtab_##sym }struct kernel_symbol {
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Matthias Maennich
maintainerPATCH v5 3/11 module: add support for symbol namespaces.
In reply to Matthias MaennichThe EXPORT_SYMBOL_NS() and EXPORT_SYMBOL_NS_GPL() macros can be used to export a symbol to a specific namespace. There are no _GPL_FUTURE and _UNUSED variants because these are currently unused, and I'm not sure they are necessary.
I didn't add EXPORT_SYMBOL_NS() for ASM exports; this patch sets the namespace of ASM exports to NULL by default. In case of relative references, it will be relocatable to NULL. If there's a need, this should be pretty easy to add.
A module that wants to use a symbol exported to a namespace must add a MODULE_IMPORT_NS() statement to their module code; otherwise, modpost will complain when building the module, and the kernel module loader will emit an error and fail when loading the module.
MODULE_IMPORT_NS() adds a modinfo tag 'import_ns' to the module. That tag can be observed by the modinfo command, modpost and kernel/module.c at the time of loading the module.
The ELF symbols are renamed to include the namespace with an asm label; for example, symbol 'usb_stor_suspend' in namespace USB_STORAGE becomes 'usb_stor_suspend.USB_STORAGE'. This allows modpost to do namespace checking, without having to go through all the effort of parsing ELF and relocation records just to get to the struct kernel_symbols.
On x86_64 I saw no difference in binary size (compression), but at runtime this will require a word of memory per export to hold the namespace. An alternative could be to store namespaced symbols in their own section and use a separate 'struct namespaced_kernel_symbol' for that section, at the cost of making the module loader more complex.
--- include/asm-generic/export.h | 6 +-- include/linux/export.h | 91 +++++++++++++++++++++++++++++------- include/linux/module.h | 2 + kernel/module.c | 43 +++++++++++++++++ 4 files changed, 123 insertions(+), 19 deletions(-)
include/asm-generic/export.h +3 -3
@@ -17,11 +17,11 @@ .macro __put, val, name#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS - .long \val - ., \name - . + .long \val - ., \name - ., 0 - .#elif defined(CONFIG_64BIT ) - .quad \val, \name + .quad \val, \name, 0#else - .long \val, \name + .long \val, \name, 0#endif .endm
include/linux/export.h +75 -16
167 lines not on this page · raw message
include/linux/module.h +2 -0
@@ -280,6 +280,8 @@ struct notifier_block;#ifdef CONFIG_MODULES +#define MODULE_IMPORT_NS (ns) MODULE_INFO(import_ns, #ns) +extern int modules_disabled;/* for sysctl */ /* Get/put a kernel symbol (calls must be symmetric) */ void *__symbol_get (const char *symbol);
kernel/module.c +43 -0
61 lines not on this page · raw message
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Matthias Maennich
maintainerPATCH v5 4/11 modpost: add support for symbol namespaces
In reply to Matthias MaennichAdd support for symbols that are exported into namespaces. For that, extract any namespace suffix from the symbol name. In addition, emit a warning whenever a module refers to an exported symbol without explicitly importing the namespace that it is defined in. This patch consistently adds the namespace suffix to symbol names exported into Module.symvers.
Example warning emitted by modpost in case of the above violation:
WARNING: module ums-usbat uses symbol usb_stor_resume from namespace USB_STORAGE, but does not import it.
--- Documentation/kbuild/modules.rst | 7 ++- scripts/export_report.pl | 2 +- scripts/mod/modpost.c | 104 ++++++++++++++++++++++++++----- scripts/mod/modpost.h | 7 +++ 4 files changed, 101 insertions(+), 19 deletions(-)
Documentation/kbuild/modules.rst +5 -2
@@ -470,9 +470,12 @@ build. The syntax of the Module.symvers file is:: - <CRC> <Symbol> <module> + <CRC> <Symbol> <Namespace> <Module> <Export Type> - 0x2d036834 scsi_remove_host drivers/scsi/scsi_mod + 0xe1cc2a05 usb_stor_suspend USB_STORAGE drivers/usb/storage/usb-storage EXPORT_SYMBOL_GPL + + The fields are separated by tabs and values may be empty (e.g. + if no namespace is defined for an exported symbol). For a kernel build without CONFIG_MODVERSIONS enabled, the CRC would read 0x00000000.
scripts/export_report.pl +1 -1
@@ -94,7 +94,7 @@ if (defined $opt{'o'}) { # while ( <$module_symvers> ) { chomp; - my (undef, $symbol, $module, $gpl) = split; + my (undef, $symbol, $namespace, $module, $gpl) = split('\t'); $SYMBOL { $symbol } = [ $module , "0" , $symbol, $gpl]; } close($module_symvers);
scripts/mod/modpost.c +88 -16
192 lines not on this page · raw message
scripts/mod/modpost.h +7 -0
@@ -109,6 +109,11 @@ buf_printf(struct buffer *buf, const char *fmt, ...);void buf_write (struct buffer *buf,const char *s,int len); +struct namespace_list { +struct namespace_list *next; +char namespace[0 ]; +}; +struct module {struct module *next;const char *name;
@@ -121,6 +126,8 @@ struct module {struct buffer dev_table_buf;char srcversion[25 ];int is_dot_o; +// Actual imported namespaces +struct namespace_list *imported_namespaces; };struct elf_info {
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
PATCH 1/1 modpost: Copy namespace string into 'struct symbol'
When building an out-of-tree module I was receiving many warnings from modpost like:
WARNING: module dahdi_vpmadt032_loader uses symbol __kmalloc from namespace ts/dahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: module dahdi_vpmadt032_loader uses symbol vpmadtreg_register from namespace linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: module dahdi_vpmadt032_loader uses symbol param_ops_int from namespace ahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: module dahdi_vpmadt032_loader uses symbol __init_waitqueue_head from namespace ux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
...
The fundamental issue appears to be that read_dump() is passing a pointer to a statically allocated buffer for the namespace which is reused as the file is parsed.
This change makes it so that 'struct symbol' holds a copy of the namespace string in the same way that it holds a copy of the symbol string. Because a copy is being made, handle_modversion can now free the temporary copy
---
Hi,
I didn't test that this change works with the namespaces, or investigate why read_dump() is only called first while building out-of-tree modules, but it does seem correct to me for the symbol to own the memory backing the namespace string.
I also realize I'm jumping the gun a bit by testing against master before 5.4-rc1 is tagged.
Shaun
scripts/mod/modpost.c | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-)
scripts/mod/modpost.c +29 -2
@@ -364,6 +364,24 @@ static const char *sym_extract_namespace(const char **symname)return NULL ; } +static const char *dup_namespace (const char *namespace) +{ +if (!namespace || (namespace[0 ] =='\0' )) +return NULL ; +return NOFAIL (strdup (namespace)); +} + +static bool is_equal (const char *n1,const char *n2) +{ +if (n1 && !n2) +return false; +if (!n1 && n2) +return false; +if (!n1 && !n2) +return true; +return strcmp (n1, n2) ==0 ; +} +/** * Add an exported symbol - it may have already been added without a * CRC, in this case just update the CRC
@@ -375,7 +393,7 @@ static struct symbol *sym_add_exported(const char *name, const char *namespace,if (!s) { s =new_symbol (name, mod, export); - s->namespace = namespace; + s->namespace =dup_namespace (namespace); }else {if (!s->preloaded) { warn("%s: '%s' exported twice. Previous export was in %s%s\n",
@@ -384,6 +402,12 @@ static struct symbol *sym_add_exported(const char *name, const char *namespace, }else {/* In case Module.symvers was out of date */ s->module = mod; + +/* In case the namespace was out of date */ +if (!is_equal (s->namespace, namespace)) { +free ((char *)s->namespace); + s->namespace =dup_namespace (namespace); + } } } s->preloaded =0 ;
@@ -672,7 +696,6 @@ static void handle_modversions(struct module *mod, struct elf_info *info,unsigned int crc;enum export export;bool is_crc = false; -const char *name, *namespace;if ((!is_vmlinux (mod->name) || mod->is_dot_o) &&strstarts (symname,"__ksymtab" ))
@@ -744,9 +767,13 @@ static void handle_modversions(struct module *mod, struct elf_info *info,default :/* All exported symbols */ if (strstarts (symname,"__ksymtab_" )) { +const char *name, *namespace; + name = symname +strlen ("__ksymtab_" ); namespace =sym_extract_namespace (&name);sym_add_exported (name, namespace, mod, export); +if (namespace) +free ((char *)name); }if (strcmp (symname,"init_module" ) ==0 ) mod->has_init =1 ;
Signature · 1 line
2.17.1
Re: [PATCH] modpost: Copy namespace string into 'struct symbol'
Quoted 29 lines · Shaun Ruffell
When building an out-of-tree module I was receiving many warnings from modpost like:
WARNING: module
dahdi_vpmadt032_loaderuses symbol__kmallocfrom namespacets/dahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolvpmadtreg_registerfrom namespacelinux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolparam_ops_intfrom namespaceahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbol__init_waitqueue_headfrom namespaceux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
...The fundamental issue appears to be that
read_dump()is passing a pointer to a statically allocated buffer for the namespace which is reused as the file is parsed.This change makes it so that 'struct symbol' holds a copy of the namespace string in the same way that it holds a copy of the symbol string. Because a copy is being made,
handle_modversioncan now free the temporary copyFixes cb9b55d21fe0 ("modpost: add support for symbol namespaces")Cc Martijn Coenen <[email protected]>Cc Joel Fernandes (Google) <[email protected]>Cc Greg Kroah-Hartman <[email protected]>Cc Matthias Maennich <[email protected]>Cc Jessica Yu <[email protected]>Signed-off-by Shaun Ruffell <[email protected]>---
Hi,
Quoted 7 lines
I didn't test that this change works with the namespaces, or investigate why
read_dump()is only called first while building out-of-tree modules, but it does seem correct to me for the symbol to own the memory backing the namespace string.I also realize I'm jumping the gun a bit by testing against master before 5.4-rc1 is tagged.
Yes!!!
This fixes the issue that I reported to Mattias a few days ago on irc. I am hitting this by just trying to build a single directory work of modules:
make M=drivers/usb/
I just tested this patch and it works for me, thanks so much!
Matthias Maennich
maintainerRe: [PATCH] modpost: Copy namespace string into 'struct symbol'
In reply to Shaun RuffellQuoted 9 lines · Shaun Ruffell
When building an out-of-tree module I was receiving many warnings from modpost like:
WARNING: module
dahdi_vpmadt032_loaderuses symbol__kmallocfrom namespacets/dahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolvpmadtreg_registerfrom namespacelinux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolparam_ops_intfrom namespaceahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbol__init_waitqueue_headfrom namespaceux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
...
Quoted 3 lines
The fundamental issue appears to be that
read_dump()is passing a pointer to a statically allocated buffer for the namespace which is reused as the file is parsed.
Hi Shaun,
Thanks for working on this. I think you are right about the root cause of this. I will have a closer look at your fix later today.
Quoted 89 lines
This change makes it so that 'struct symbol' holds a copy of the namespace string in the same way that it holds a copy of the symbol string. Because a copy is being made,
handle_modversioncan now free the temporary copyFixes cb9b55d21fe0 ("modpost: add support for symbol namespaces")Cc Martijn Coenen <[email protected]>Cc Joel Fernandes (Google) <[email protected]>Cc Greg Kroah-Hartman <[email protected]>Cc Matthias Maennich <[email protected]>Cc Jessica Yu <[email protected]>Signed-off-by Shaun Ruffell <[email protected]>---
Hi,
I didn't test that this change works with the namespaces, or investigate why
read_dump()is only called first while building out-of-tree modules, but it does seem correct to me for the symbol to own the memory backing the namespace string.I also realize I'm jumping the gun a bit by testing against master before 5.4-rc1 is tagged.
Shaun
scripts/mod/modpost.c| 31 +++++++++++++++++++++++++++++--1 file changed, 29 insertions(+), 2 deletions(-)scripts/mod/modpost.c +25
-2@@ -364,6 +364,24 @@ static const char *sym_extract_namespace(const char **symname)return NULL ; } +static const char *dup_namespace (const char *namespace) +{ +if (!namespace || (namespace[0 ] =='\0' )) +return NULL ; +return NOFAIL (strdup (namespace)); +} + +static bool is_equal (const char *n1,const char *n2) +{ +if (n1 && !n2) +return false; +if (!n1 && n2) +return false; +if (!n1 && !n2) +return true; +return strcmp (n1, n2) ==0 ; +} +/** * Add an exported symbol - it may have already been added without a * CRC, in this case just update the CRC @@ -375,7 +393,7 @@ static struct symbol *sym_add_exported(const char *name, const char *namespace,if (!s) { s =new_symbol (name, mod, export); - s->namespace = namespace; + s->namespace =dup_namespace (namespace); }else {if (!s->preloaded) { warn("%s: '%s' exported twice. Previous export was in %s%s\n",@@ -384,6 +402,12 @@ static struct symbol *sym_add_exported(const char *name, const char *namespace, }else {/* In case Module.symvers was out of date */ s->module = mod; + +/* In case the namespace was out of date */ +if (!is_equal (s->namespace, namespace)) { +free ((char *)s->namespace); + s->namespace =dup_namespace (namespace); + } } } s->preloaded =0 ;@@ -672,7 +696,6 @@ static void handle_modversions(struct module *mod, struct elf_info *info,unsigned int crc;enum export export;bool is_crc = false; -const char *name, *namespace;if ((!is_vmlinux (mod->name) || mod->is_dot_o) &&strstarts (symname,"__ksymtab" ))
scripts/mod/modpost.c static void handle_modversions(struct module *mod, struct elf_info *info, · line 776
Quoted 10 lines
scripts/mod/modpost.c +4
-0@@ -744,9 +767,13 @@ static void handle_modversions(struct module *mod, struct elf_info *info,default :/* All exported symbols */ if (strstarts (symname,"__ksymtab_" )) { +const char *name, *namespace; + name = symname +strlen ("__ksymtab_" ); namespace =sym_extract_namespace (&name);sym_add_exported (name, namespace, mod, export); +if (namespace) +free ((char *)name);
This probably should free namespace instead.
Quoted 5 lines
scripts/mod/modpost.c +0
-0}if (strcmp (symname,"init_module" ) ==0 ) mod->has_init =1 ;Signature · 1 line
2.17.1
Cheers,
Matthias
Re: [PATCH] modpost: Copy namespace string into 'struct symbol'
Quoted 10 lines · Matthias Maennich
Quoted 9 lines · Shaun Ruffell
When building an out-of-tree module I was receiving many warnings from modpost like:
WARNING: module
dahdi_vpmadt032_loaderuses symbol__kmallocfrom namespacets/dahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolvpmadtreg_registerfrom namespacelinux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolparam_ops_intfrom namespaceahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbol__init_waitqueue_headfrom namespaceux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
...
Quoted 8 lines
Quoted 3 lines
The fundamental issue appears to be that
read_dump()is passing a pointer to a statically allocated buffer for the namespace which is reused as the file is parsed.Hi Shaun,
Thanks for working on this. I think you are right about the root cause of this. I will have a closer look at your fix later today.
Thanks Matthias.
Quoted 6 lines
Quoted 6 lines
scripts/mod/modpost.c +0
-1@@ -672,7 +696,6 @@ static void handle_modversions(struct module *mod, struct elf_info *info,unsigned int crc;enum export export;bool is_crc = false; -const char *name, *namespace;
Quoted 15 lines
scripts/mod/modpost.c static void handle_modversions(struct module *mod, struct elf_info *info, · line 776
Quoted 13 lines
scripts/mod/modpost.c +4
-0if ((!is_vmlinux (mod->name) || mod->is_dot_o) &&strstarts (symname,"__ksymtab" ))@@ -744,9 +767,13 @@ static void handle_modversions(struct module *mod, struct elf_info *info,default :/* All exported symbols */ if (strstarts (symname,"__ksymtab_" )) { +const char *name, *namespace; + name = symname +strlen ("__ksymtab_" ); namespace =sym_extract_namespace (&name);sym_add_exported (name, namespace, mod, export); +if (namespace) +free ((char *)name);This probably should free namespace instead.
Given the implementation of sym_extract_namespace below, I believe free((char *)name) is correct.
static const char *sym_extract_namespace(const char **symname)
{
size_t n;
char *dupsymname;
n = strcspn(*symname, ".");
if (n < strlen(*symname) - 1) {
dupsymname = NOFAIL(strdup(*symname));
dupsymname[n] = '\0';
*symname = dupsymname;
return dupsymname + n + 1;
}
return NULL;
}I agree that freeing name instead of namespace is a little surprising unless you know the implementation of sym_extract_namespace.
I thought about changing the the signature of sym_extract_namespace() to make it clear when the symname is used to return a new allocation or not, and given your comment, perhaps I should have.
Matthias Maennich
maintainerRe: [PATCH] modpost: Copy namespace string into 'struct symbol'
Quoted 15 lines · Shaun Ruffell
Quoted 14 lines · Matthias Maennich
Quoted 12 lines · Shaun Ruffell
When building an out-of-tree module I was receiving many warnings from modpost like:
WARNING: module
dahdi_vpmadt032_loaderuses symbol__kmallocfrom namespacets/dahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolvpmadtreg_registerfrom namespacelinux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolparam_ops_intfrom namespaceahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbol__init_waitqueue_headfrom namespaceux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
...The fundamental issue appears to be that
read_dump()is passing a pointer to a statically allocated buffer for the namespace which is reused as the file is parsed.
Quoted 6 lines
Quoted 4 lines
Hi Shaun,
Thanks for working on this. I think you are right about the root cause of this. I will have a closer look at your fix later today.
Thanks Matthias.
In the meantime, Masahiro came up with an alternative approach to address this problem:
https://lore.kernel.org/lkml/[email protected]/
How do you think about it? It ignores the memory allocation problem that you addressed as modpost is a host tool after all. As part of the patch series, an alternative format for the namespace ksymtab entry is suggested that also changes the way modpost has to deal with it.
Quoted 22 lines
Quoted 6 lines
Quoted 6 lines
scripts/mod/modpost.c +0
-1@@ -672,7 +696,6 @@ static void handle_modversions(struct module *mod, struct elf_info *info,unsigned int crc;enum export export;bool is_crc = false; -const char *name, *namespace;Quoted 15 lines
scripts/mod/modpost.c static void handle_modversions(struct module *mod, struct elf_info *info, · line 776
Quoted 13 lines
scripts/mod/modpost.c +4
-0if ((!is_vmlinux (mod->name) || mod->is_dot_o) &&strstarts (symname,"__ksymtab" ))@@ -744,9 +767,13 @@ static void handle_modversions(struct module *mod, struct elf_info *info,default :/* All exported symbols */ if (strstarts (symname,"__ksymtab_" )) { +const char *name, *namespace; + name = symname +strlen ("__ksymtab_" ); namespace =sym_extract_namespace (&name);sym_add_exported (name, namespace, mod, export); +if (namespace) +free ((char *)name);This probably should free namespace instead.
Quoted 2 lines
Given the implementation of
sym_extract_namespacebelow, I believefree((char *)name)is correct.
Yeah, you are right. I was just noticing the inconsistency and thought it was obviously wrong. So, I was wrong. Sorry and thanks for the explanation.
Quoted 17 lines
static const char *sym_extract_namespace(const char **symname) {
(quoted diff) +0
-0size_t n; char *dupsymname; n = strcspn(*symname, "."); if (n < strlen(*symname) - 1) { dupsymname = NOFAIL(strdup(*symname)); dupsymname[n] = '\0'; *symname = dupsymname; return dupsymname + n + 1; } return NULL; }
Quoted 6 lines
I agree that freeing name instead of namespace is a little surprising unless you know the implementation of
sym_extract_namespace.I thought about changing the the signature of
sym_extract_namespace()to make it clear when the symname is used to return a new allocation or not, and given your comment, perhaps I should have.
I would rather follow-up with Masahiro's approach for now. What do you think?
Cheers,
Matthias
Re: [PATCH] modpost: Copy namespace string into 'struct symbol'
Quoted 23 lines · Matthias Maennich
Quoted 15 lines · Shaun Ruffell
Quoted 14 lines · Matthias Maennich
Quoted 12 lines · Shaun Ruffell
When building an out-of-tree module I was receiving many warnings from modpost like:
WARNING: module
dahdi_vpmadt032_loaderuses symbol__kmallocfrom namespacets/dahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolvpmadtreg_registerfrom namespacelinux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbolparam_ops_intfrom namespaceahdi-linux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
WARNING: moduledahdi_vpmadt032_loaderuses symbol__init_waitqueue_headfrom namespaceux/drivers/dahdi/dahdi-version.o: ..., but does not import it.
...The fundamental issue appears to be that
read_dump()is passing a pointer to a statically allocated buffer for the namespace which is reused as the file is parsed.Quoted 6 lines
Quoted 4 lines
Hi Shaun,
Thanks for working on this. I think you are right about the root cause of this. I will have a closer look at your fix later today.
Thanks Matthias.
Quoted 7 lines
In the meantime, Masahiro came up with an alternative approach to address this problem:
https://lore.kernel.org/lkml/[email protected]/
How do you think about it? It ignores the memory allocation problem that you addressed as modpost is a host tool after all. As part of the patch series, an alternative format for the namespace ksymtab entry is suggested that also changes the way modpost has to deal with it.
Masahiro's patch set looks good to me.
My only comment would be that I felt it preferable for sym_add_exported() to treat the two string arguments passed to it the same way. I feel the way it is currently violates the princple of least surprise. However I accept this is just my personal opinion.
Quoted 49 lines
Quoted 22 lines
Quoted 6 lines
Quoted 6 lines
scripts/mod/modpost.c +0
-1@@ -672,7 +696,6 @@ static void handle_modversions(struct module *mod, struct elf_info *info,unsigned int crc;enum export export;bool is_crc = false; -const char *name, *namespace;Quoted 15 lines
scripts/mod/modpost.c static void handle_modversions(struct module *mod, struct elf_info *info, · line 776
Quoted 13 lines
scripts/mod/modpost.c +4
-0if ((!is_vmlinux (mod->name) || mod->is_dot_o) &&strstarts (symname,"__ksymtab" ))@@ -744,9 +767,13 @@ static void handle_modversions(struct module *mod, struct elf_info *info,default :/* All exported symbols */ if (strstarts (symname,"__ksymtab_" )) { +const char *name, *namespace; + name = symname +strlen ("__ksymtab_" ); namespace =sym_extract_namespace (&name);sym_add_exported (name, namespace, mod, export); +if (namespace) +free ((char *)name);This probably should free namespace instead.
Quoted 2 lines
Given the implementation of
sym_extract_namespacebelow, I believefree((char *)name)is correct.Yeah, you are right. I was just noticing the inconsistency and thought it was obviously wrong. So, I was wrong. Sorry and thanks for the explanation.
Quoted 20 lines
static const char *sym_extract_namespace(const char **symname) {
(quoted diff) +0
-0size_t n; char *dupsymname; n = strcspn(*symname, "."); if (n < strlen(*symname) - 1) { dupsymname = NOFAIL(strdup(*symname)); dupsymname[n] = '\0'; *symname = dupsymname; return dupsymname + n + 1; } return NULL; }I agree that freeing name instead of namespace is a little surprising unless you know the implementation of
sym_extract_namespace.
Quoted 6 lines
Quoted 3 lines
I thought about changing the the signature of
sym_extract_namespace()to make it clear when the symname is used to return a new allocation or not, and given your comment, perhaps I should have.I would rather follow-up with Masahiro's approach for now. What do you think?
I agree that following-up with Masahiro's patch set is the better option.
Cheers,
Shaun
Matthias Maennich
maintainerPATCH v5 5/11 module: add config option MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS
In reply to Matthias MaennichIf MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is enabled (default=n), the requirement for modules to import all namespaces that are used by the module is relaxed.
Enabling this option effectively allows (invalid) modules to be loaded while only a warning is emitted.
Disabling this option keeps the enforcement at module loading time and loading is denied if the module's imports are not satisfactory.
--- init/Kconfig | 13 +++++++++++++ kernel/module.c | 11 +++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-)
init/Kconfig +13 -0
@@ -2119,6 +2119,19 @@ config MODULE_COMPRESS_XZ endchoice +config MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS + bool "Allow loading of modules with missing namespace imports" + help + Symbols exported with EXPORT_SYMBOL_NS*() are considered exported in + a namespace. A module that makes use of a symbol exported with such a + namespace is required to import the namespace via MODULE_IMPORT_NS(). + There is no technical reason to enforce correct namespace imports, + but it creates consistency between symbols defining namespaces and + users importing namespaces they make use of. This option relaxes this + requirement and lifts the enforcement when loading a module. + + If unsure, say N. + config TRIM_UNUSED_KSYMS bool "Trim unused exported kernel symbols" depends on MODULES && !UNUSED_SYMBOLS
kernel/module.c +9 -2
@@ -1408,9 +1408,16 @@ static int verify_namespace_is_imported(const struct load_info *info, imported_namespace =get_next_modinfo ( info,"import_ns" , imported_namespace); } -pr_err ("%s: module uses symbol (%s) from namespace %s, but does not import it.\n" , - mod->name,kernel_symbol_name (sym), namespace); +#ifdef CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS + pr_warn( +#else + pr_err( +#endif +"%s: module uses symbol (%s) from namespace %s, but does not import it.\n" , + mod->name, kernel_symbol_name(sym), namespace); +#ifndef CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS return -EINVAL ; +#endif }return 0 ; }
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Matthias Maennich
maintainerPATCH v5 6/11 export: allow definition default namespaces in Makefiles or sources
In reply to Matthias MaennichTo avoid excessive usage of EXPORT_SYMBOL_NS(sym, MY_NAMESPACE), where MY_NAMESPACE will always be the namespace we are exporting to, allow exporting all definitions of EXPORT_SYMBOL() and friends by defining DEFAULT_SYMBOL_NAMESPACE.
For example, to export all symbols defined in usb-common into the namespace USB_COMMON, add a line like this to drivers/usb/common/Makefile:
ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_COMMON
That is equivalent to changing all EXPORT_SYMBOL(sym) definitions to EXPORT_SYMBOL_NS(sym, USB_COMMON). Subsequently all symbol namespaces functionality will apply.
Another way of making use of this feature is to define the namespace within source or header files similar to how TRACE_SYSTEM defines are used:
#undef DEFAULT_SYMBOL_NAMESPACE
#define DEFAULT_SYMBOL_NAMESPACE USB_COMMON
Please note that, as opposed to TRACE_SYSTEM, DEFAULT_SYMBOL_NAMESPACE has to be defined before including include/linux/export.h.
If DEFAULT_SYMBOL_NAMESPACE is defined, a symbol can still be exported to another namespace by using EXPORT_SYMBOL_NS() and friends with explicitly specifying the namespace.
--- include/linux/export.h | 6 ++++++ 1 file changed, 6 insertions(+)
include/linux/export.h +6 -0
@@ -166,6 +166,12 @@ struct kernel_symbol {#define __EXPORT_SYMBOL ___EXPORT_SYMBOL#endif +#ifdef DEFAULT_SYMBOL_NAMESPACE +#undef __EXPORT_SYMBOL +#define __EXPORT_SYMBOL (sym, sec) \ + __EXPORT_SYMBOL_NS(sym, sec, DEFAULT_SYMBOL_NAMESPACE) +#endif +#define EXPORT_SYMBOL (sym) __EXPORT_SYMBOL(sym, "")#define EXPORT_SYMBOL_GPL (sym) __EXPORT_SYMBOL(sym, "_gpl")#define EXPORT_SYMBOL_GPL_FUTURE (sym) __EXPORT_SYMBOL(sym, "_gpl_future")
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Matthias Maennich
maintainerPATCH v5 7/11 modpost: add support for generating namespace dependencies
In reply to Matthias MaennichThis patch adds an option to modpost to generate a <module>.ns_deps file per module, containing the namespace dependencies for that module.
E.g. if the linked module my-module.ko would depend on the symbol myfunc.MY_NS in the namespace MY_NS, the my-module.ns_deps file created by modpost would contain the entry MY_NS to express the namespace dependency of my-module imposed by using the symbol myfunc.
These files can subsequently be used by static analysis tools (like coccinelle scripts) to address issues with missing namespace imports. A later patch of this series will introduce such a script 'nsdeps' and a corresponding make target to automatically add missing MODULE_IMPORT_NS() definitions to the module's sources. For that it uses the information provided in the generated .ns_deps files.
--- .gitignore | 1 + Makefile | 2 +- scripts/mod/modpost.c | 54 +++++++++++++++++++++++++++++++++++++++---- scripts/mod/modpost.h | 2 ++ 4 files changed, 53 insertions(+), 6 deletions(-)
.gitignore +1 -0
@@ -32,6 +32,7 @@ *.lzo *.mod *.mod.c +*.ns_deps *.o *.o.* *.order
Makefile +1 -1
@@ -1669,7 +1669,7 @@ clean: $(clean-dirs) -o -name '*.ko.*' \ -o -name '*.dtb' -o -name '*.dtb.S' -o -name '*.dt.yaml' \ -o -name '*.dwo' -o -name '*.lst' \ - -o -name '*.su' -o -name '*.mod' \ + -o -name '*.su' -o -name '*.mod' -o -name '*.ns_deps' \ -o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \ -o -name '*.lex.c' -o -name '*.tab.[ch]' \ -o -name '*.asn1.[ch]' \
scripts/mod/modpost.c +49 -5
96 lines not on this page · raw message
scripts/mod/modpost.h +2 -0
@@ -126,6 +126,8 @@ struct module {struct buffer dev_table_buf;char srcversion[25 ];int is_dot_o; +// Required namespace dependencies +struct namespace_list *required_namespaces;// Actual imported namespaces struct namespace_list *imported_namespaces; };
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Matthias Maennich
maintainerPATCH v5 8/11 scripts: Coccinelle script for namespace dependencies.
In reply to Matthias MaennichA script that uses the '<module>.ns_deps' files generated by modpost to automatically add the required symbol namespace dependencies to each module.
Usage:
1) Move some symbols to a namespace with EXPORT_SYMBOL_NS() or define DEFAULT_SYMBOL_NAMESPACE
2) Run 'make' (or 'make modules') and get warnings about modules not importing that namespace.
3) Run 'make nsdeps' to automatically add required import statements to said modules.
This makes it easer for subsystem maintainers to introduce and maintain symbol namespaces into their codebase.
--- MAINTAINERS | 5 ++ Makefile | 12 +++++ scripts/Makefile.modpost | 4 +- scripts/coccinelle/misc/add_namespace.cocci | 23 ++++++++ scripts/nsdeps | 58 +++++++++++++++++++++ 5 files changed, 101 insertions(+), 1 deletion(-) create mode 100644 scripts/coccinelle/misc/add_namespace.cocci create mode 100644 scripts/nsdeps
MAINTAINERS +5 -0
@@ -11436,6 +11436,11 @@ S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git F: tools/include/nolibc/ +NSDEPS +M: Matthias Maennich <[email protected]> +S: Maintained +F: scripts/nsdeps + NTB AMD DRIVER M: Shyam Sundar S K <[email protected]> L: [email protected]
Makefile +12 -0
@@ -1500,6 +1500,9 @@ help: @echo ' headerdep - Detect inclusion cycles in headers' @echo ' coccicheck - Check with Coccinelle' @echo '' + @echo 'Tools:' + @echo ' nsdeps - Generate missing symbol namespace dependencies' + @echo '' @echo 'Kernel selftest:' @echo ' kselftest - Build and run kernel selftest (run as root)' @echo ' Build, install, and boot kernel before'
@@ -1687,6 +1690,15 @@ quiet_cmd_tags = GEN $@ tags TAGS cscope gtags: FORCE $(call cmd,tags) +# Script to generate missing namespace dependencies +# --------------------------------------------------------------------------- + +PHONY += nsdeps + +nsdeps: modules + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost nsdeps + $(Q)$(CONFIG_SHELL) $(srctree)/scripts/$@ + # Scripts to check various things for consistency # ---------------------------------------------------------------------------
scripts/Makefile.modpost +3 -1
@@ -56,7 +56,8 @@ MODPOST = scripts/mod/modpost \ $(if $(KBUILD_EXTMOD),$(addprefix -e ,$(KBUILD_EXTRA_SYMBOLS))) \ $(if $(KBUILD_EXTMOD),-o $(modulesymfile)) \ $(if $(CONFIG_SECTION_MISMATCH_WARN_ONLY),,-E) \ - $(if $(KBUILD_MODPOST_WARN),-w) + $(if $(KBUILD_MODPOST_WARN),-w) \ + $(if $(filter nsdeps,$(MAKECMDGOALS)),-d) ifdef MODPOST_VMLINUX
@@ -134,6 +135,7 @@ $(modules): %.ko :%.o %.mod.o FORCE targets += $(modules) +nsdeps: __modpost # Add FORCE to the prequisites of a target to force it to be always rebuilt. # ---------------------------------------------------------------------------
scripts/coccinelle/misc/add_namespace.cocci new file +23 -0
@@ -0,0 +1,23 @@ +// SPDX-License-Identifier: GPL-2.0-only +// +/// Adds missing MODULE_IMPORT_NS statements to source files +/// +/// This script is usually called from scripts/nsdeps with -D ns=<namespace> to +/// add a missing namespace tag to a module source file. +/// + +@has_ns_import@ +declarer name MODULE_IMPORT_NS; +identifier virtual.ns; +@@ +MODULE_IMPORT_NS(ns); + +// Add missing imports, but only adjacent to a MODULE_LICENSE statement. +// That ensures we are adding it only to the main module source file. +@do_import depends on !has_ns_import@ +declarer name MODULE_LICENSE; +expression license; +identifier virtual.ns; +@@ +MODULE_LICENSE(license); ++ MODULE_IMPORT_NS(ns);
scripts/nsdeps new file +58 -0
58 lines not on this page · raw message
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Matthias Maennich
maintainerPATCH v5 9/11 docs: Add documentation for Symbol Namespaces
In reply to Matthias MaennichDescribe using Symbol Namespaces from a perspective of a user. I.e. module authors or subsystem maintainers.
--- Documentation/kbuild/namespaces.rst | 154 +++++++++++++++++++++++ Documentation/kernel-hacking/hacking.rst | 18 +++ 2 files changed, 172 insertions(+) create mode 100644 Documentation/kbuild/namespaces.rst
Documentation/kbuild/namespaces.rst new file +154 -0
@@ -0,0 +1,154 @@ +================= +Symbol Namespaces +================= + +The following document describes how to use Symbol Namespaces to structure the +export surface of in-kernel symbols exported through the family of +EXPORT_SYMBOL() macros. + +.. Table of Contents + + === 1 Introduction + === 2 How to define Symbol Namespaces + --- 2.1 Using the EXPORT_SYMBOL macros + --- 2.2 Using the DEFAULT_SYMBOL_NAMESPACE define + === 3 How to use Symbols exported in Namespaces + === 4 Loading Modules that use namespaced Symbols + === 5 Automatically creating MODULE_IMPORT_NS statements + +1. Introduction +=============== + +Symbol Namespaces have been introduced as a means to structure the export +surface of the in-kernel API. It allows subsystem maintainers to partition +their exported symbols into separate namespaces. That is useful for +documentation purposes (think of the SUBSYSTEM_DEBUG namespace) as well as for +limiting the availability of a set of symbols for use in other parts of the +kernel. As of today, modules that make use of symbols exported into namespaces, +are required to import the namespace. Otherwise the kernel will, depending on +its configuration, reject loading the module or warn about a missing import. + +2. How to define Symbol Namespaces +================================== + +Symbols can be exported into namespace using different methods. All of them are +changing the way EXPORT_SYMBOL and friends are instrumented to create ksymtab +entries. + +2.1 Using the EXPORT_SYMBOL macros +================================== + +In addition to the macros EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL(), that allow +exporting of kernel symbols to the kernel symbol table, variants of these are +available to export symbols into a certain namespace: EXPORT_SYMBOL_NS() and +EXPORT_SYMBOL_NS_GPL(). They take one additional argument: the namespace. +Please note that due to macro expansion that argument needs to be a +preprocessor symbol. E.g. to export the symbol `usb_stor_suspend` into the +namespace `USB_STORAGE`, use:: + + EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE); + +The corresponding ksymtab entry struct `kernel_symbol` will have the member +`namespace` set accordingly. A symbol that is exported without a namespace will +refer to `NULL`. There is no default namespace if none is defined. `modpost` +and kernel/module.c make use the namespace at build time or module load time, +respectively. + +2.2 Using the DEFAULT_SYMBOL_NAMESPACE define +============================================= + +Defining namespaces for all symbols of a subsystem can be very verbose and may +become hard to maintain. Therefore a default define (DEFAULT_SYMBOL_NAMESPACE) +is been provided, that, if set, will become the default for all EXPORT_SYMBOL() +and EXPORT_SYMBOL_GPL() macro expansions that do not specify a namespace. + +There are multiple ways of specifying this define and it depends on the +subsystem and the maintainer's preference, which one to use. The first option +is to define the default namespace in the `Makefile` of the subsystem. E.g. to +export all symbols defined in usb-common into the namespace USB_COMMON, add a +line like this to drivers/usb/common/Makefile:: + + ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_COMMON + +That will affect all EXPORT_SYMBOL() and EXPORT_SYMBOL_GPL() statements. A +symbol exported with EXPORT_SYMBOL_NS() while this definition is present, will +still be exported into the namespace that is passed as the namespace argument +as this argument has preference over a default symbol namespace. + +A second option to define the default namespace is directly in the compilation +unit as preprocessor statement. The above example would then read:: + + #undef DEFAULT_SYMBOL_NAMESPACE + #define DEFAULT_SYMBOL_NAMESPACE USB_COMMON + +within the corresponding compilation unit before any EXPORT_SYMBOL macro is +used. + +3. How to use Symbols exported in Namespaces +============================================ + +In order to use symbols that are exported into namespaces, kernel modules need +to explicitly import these namespaces. Otherwise the kernel might reject to +load the module. The module code is required to use the macro MODULE_IMPORT_NS +for the namespaces it uses symbols from. E.g. a module using the +usb_stor_suspend symbol from above, needs to import the namespace USB_STORAGE +using a statement like:: + + MODULE_IMPORT_NS(USB_STORAGE); + +This will create a `modinfo` tag in the module for each imported namespace. +This has the side effect, that the imported namespaces of a module can be +inspected with modinfo:: + + $ modinfo drivers/usb/storage/ums-karma.ko + [...] + import_ns: USB_STORAGE + [...] + + +It is advisable to add the MODULE_IMPORT_NS() statement close to other module +metadata definitions like MODULE_AUTHOR() or MODULE_LICENSE(). Refer to section +5. for a way to create missing import statements automatically. + +4. Loading Modules that use namespaced Symbols +============================================== + +At module loading time (e.g. `insmod`), the kernel will check each symbol +referenced from the module for its availability and whether the namespace it +might be exported to has been imported by the module. The default behaviour of +the kernel is to reject loading modules that don't specify sufficient imports. +An error will be logged and loading will be failed with EINVAL. In order to +allow loading of modules that don't satisfy this precondition, a configuration +option is available: Setting MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=y will +enable loading regardless, but will emit a warning. + +5. Automatically creating MODULE_IMPORT_NS statements +===================================================== + +Missing namespaces imports can easily be detected at build time. In fact, +modpost will emit a warning if a module uses a symbol from a namespace +without importing it. +MODULE_IMPORT_NS() statements will usually be added at a definite location +(along with other module meta data). To make the life of module authors (and +subsystem maintainers) easier, a script and make target is available to fixup +missing imports. Fixing missing imports can be done with:: + + $ make nsdeps + +A typical scenario for module authors would be:: + + - write code that depends on a symbol from a not imported namespace + - `make` + - notice the warning of modpost telling about a missing import + - run `make nsdeps` to add the import to the correct code location + +For subsystem maintainers introducing a namespace, the steps are very similar. +Again, `make nsdeps` will eventually add the missing namespace imports for +in-tree modules:: + + - move or add symbols to a namespace (e.g. with EXPORT_SYMBOL_NS()) + - `make` (preferably with an allmodconfig to cover all in-kernel + modules) + - notice the warning of modpost telling about a missing import + - run `make nsdeps` to add the import to the correct code location +
Documentation/kernel-hacking/hacking.rst +18 -0
@@ -594,6 +594,24 @@ internal implementation issue, and not really an interface. Some maintainers and developers may however require EXPORT_SYMBOL_GPL() when adding any new APIs or functionality. +:c:func:`EXPORT_SYMBOL_NS()` +---------------------------- + +Defined in ``include/linux/export.h`` + +This is the variant of `EXPORT_SYMBOL()` that allows specifying a symbol +namespace. Symbol Namespaces are documented in +``Documentation/kbuild/namespaces.rst``. + +:c:func:`EXPORT_SYMBOL_NS_GPL()` +-------------------------------- + +Defined in ``include/linux/export.h`` + +This is the variant of `EXPORT_SYMBOL_GPL()` that allows specifying a symbol +namespace. Symbol Namespaces are documented in +``Documentation/kbuild/namespaces.rst``. + Routines and Conventions ========================
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Matthias Maennich
maintainerPATCH v5 10/11 usb-storage: remove single-use define for debugging
In reply to Matthias MaennichUSB_STORAGE was defined as "usb-storage: " and used in a single location as argument to printk. In order to be able to use the name 'USB_STORAGE', drop the definition and use the string directly for the printk call.
--- drivers/usb/storage/debug.h | 2 -- drivers/usb/storage/scsiglue.c | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-)
drivers/usb/storage/debug.h +0 -2
@@ -29,8 +29,6 @@#include <linux/kernel.h> -#define USB_STORAGE "usb-storage: " -#ifdef CONFIG_USB_STORAGE_DEBUG void usb_stor_show_command (const struct us_data *us,struct scsi_cmnd *srb); void usb_stor_show_sense(const struct us_data *us, unsigned char key,
drivers/usb/storage/scsiglue.c +1 -1
@@ -379,7 +379,7 @@ static int queuecommand_lck(struct scsi_cmnd *srb,/* check for state-transition errors */ if (us->srb !=NULL ) { - printk(KERN_ERR USB_STORAGE "Error in %s: us->srb = %p\n", +printk (KERN_ERR "usb-storage: Error in %s: us->srb = %p\n" , __func__, us->srb);return SCSI_MLQUEUE_HOST_BUSY ; }
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Re: [PATCH v5 10/11] usb-storage: remove single-use define for debugging
+++ Matthias Maennich [06/09/19 11:32 +0100]:
Quoted 7 lines
USB_STORAGEwas defined as "usb-storage: " and used in a single location as argument to printk. In order to be able to use the name 'USB_STORAGE', drop the definition and use the string directly for the printk call.Reviewed-by Greg Kroah-Hartman <[email protected]>Signed-off-by Matthias Maennich <[email protected]>
Greg, didn't you pick this patch up for usb-next already (for the 5.4 merge window)? If that's the case, I could apply the series omitting this patch (once there are no more comments or complaints).
Thanks!
Jessica
Greg KH
maintainerRe: [PATCH v5 10/11] usb-storage: remove single-use define for debugging
Quoted 6 lines · Jessica Yu
+++ Matthias Maennich [06/09/19 11:32 +0100]:
Quoted 5 lines
USB_STORAGEwas defined as "usb-storage: " and used in a single location as argument to printk. In order to be able to use the name 'USB_STORAGE', drop the definition and use the string directly for the printk call.
Quoted 6 lines
Quoted 2 lines
Reviewed-by Greg Kroah-Hartman <[email protected]>Signed-off-by Matthias Maennich <[email protected]>Greg, didn't you pick this patch up for usb-next already (for the 5.4 merge window)? If that's the case, I could apply the series omitting this patch (once there are no more comments or complaints).
Yes, I already have this in my tree, but there's no problem with you taking it in yours as I think it's needed for the one after this to build properly.
git will handle it properly when merging :)
thanks!
greg k-h
Matthias Maennich
maintainerPATCH v5 11/11 usb-storage: export symbols in USB_STORAGE namespace
In reply to Matthias MaennichModules using these symbols are required to explicitly import the namespace. This patch was generated with the following steps and serves as a reference to use the symbol namespace feature:
1) Define DEFAULT_SYMBOL_NAMESPACE in the corresponding Makefile
2) make (see warnings during modpost about missing imports)
3) make nsdeps
Instead of a DEFAULT_SYMBOL_NAMESPACE definition, the EXPORT_SYMBOL_NS variants can be used to explicitly specify the namespace. The advantage of the method used here is that newly added symbols are automatically exported and existing ones are exported without touching their respective EXPORT_SYMBOL macro expansion.
--- drivers/usb/storage/Makefile | 2 ++ drivers/usb/storage/alauda.c | 1 + drivers/usb/storage/cypress_atacb.c | 1 + drivers/usb/storage/datafab.c | 1 + drivers/usb/storage/ene_ub6250.c | 1 + drivers/usb/storage/freecom.c | 1 + drivers/usb/storage/isd200.c | 1 + drivers/usb/storage/jumpshot.c | 1 + drivers/usb/storage/karma.c | 1 + drivers/usb/storage/onetouch.c | 1 + drivers/usb/storage/realtek_cr.c | 1 + drivers/usb/storage/sddr09.c | 1 + drivers/usb/storage/sddr55.c | 1 + drivers/usb/storage/shuttle_usbat.c | 1 + drivers/usb/storage/uas.c | 1 + 15 files changed, 16 insertions(+)
drivers/usb/storage/Makefile +2 -0
@@ -8,6 +8,8 @@ ccflags-y := -I $(srctree)/drivers/scsi +ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=USB_STORAGE + obj-$(CONFIG_USB_UAS) += uas.o obj-$(CONFIG_USB_STORAGE) += usb-storage.o
drivers/usb/storage/alauda.c +1 -0
@@ -36,6 +36,7 @@MODULE_DESCRIPTION ("Driver for Alauda-based card readers" );MODULE_AUTHOR ("Daniel Drake <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );/* * Status bytes
drivers/usb/storage/cypress_atacb.c +1 -0
@@ -22,6 +22,7 @@MODULE_DESCRIPTION ("SAT support for Cypress USB/ATA bridges with ATACB" );MODULE_AUTHOR ("Matthieu Castet <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );/* * The table of devices
drivers/usb/storage/datafab.c +1 -0
@@ -54,6 +54,7 @@MODULE_DESCRIPTION ("Driver for Datafab USB Compact Flash reader" );MODULE_AUTHOR ("Jimmie Mayfield <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );struct datafab_info {unsigned long sectors;/* total sector count */
drivers/usb/storage/ene_ub6250.c +1 -0
@@ -26,6 +26,7 @@MODULE_DESCRIPTION ("Driver for ENE UB6250 reader" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );MODULE_FIRMWARE (SD_INIT1_FIRMWARE );MODULE_FIRMWARE (SD_INIT2_FIRMWARE );MODULE_FIRMWARE (SD_RW_FIRMWARE );
drivers/usb/storage/freecom.c +1 -0
@@ -29,6 +29,7 @@MODULE_DESCRIPTION ("Driver for Freecom USB/IDE adaptor" );MODULE_AUTHOR ("David Brown <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );#ifdef CONFIG_USB_STORAGE_DEBUG static void pdump (struct us_data *us,void *ibuffer,int length);
drivers/usb/storage/isd200.c +1 -0
@@ -53,6 +53,7 @@MODULE_DESCRIPTION ("Driver for In-System Design, Inc. ISD200 ASIC" );MODULE_AUTHOR ("Björn Stenberg <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );static int isd200_Initialization (struct us_data *us);
drivers/usb/storage/jumpshot.c +1 -0
@@ -51,6 +51,7 @@MODULE_DESCRIPTION ("Driver for Lexar \"Jumpshot\" Compact Flash reader" );MODULE_AUTHOR ("Jimmie Mayfield <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );/* * The table of devices
drivers/usb/storage/karma.c +1 -0
@@ -23,6 +23,7 @@MODULE_DESCRIPTION ("Driver for Rio Karma" );MODULE_AUTHOR ("Bob Copeland <[email protected]>, Keith Bennett <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );#define RIO_PREFIX "RIOP\x00"#define RIO_PREFIX_LEN 5
drivers/usb/storage/onetouch.c +1 -0
@@ -25,6 +25,7 @@MODULE_DESCRIPTION ("Maxtor USB OneTouch hard drive button driver" );MODULE_AUTHOR ("Nick Sillik <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );#define ONETOUCH_PKT_LEN 0x02#define ONETOUCH_BUTTON KEY_PROG1
drivers/usb/storage/realtek_cr.c +1 -0
@@ -35,6 +35,7 @@MODULE_DESCRIPTION ("Driver for Realtek USB Card Reader" );MODULE_AUTHOR ("wwang <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );static int auto_delink_en =1 ;module_param (auto_delink_en, int,S_IRUGO |S_IWUSR );
drivers/usb/storage/sddr09.c +1 -0
@@ -47,6 +47,7 @@MODULE_DESCRIPTION ("Driver for SanDisk SDDR-09 SmartMedia reader" );MODULE_AUTHOR ("Andries Brouwer <[email protected]>, Robert Baruch <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );static int usb_stor_sddr09_dpcm_init (struct us_data *us);static int sddr09_transport (struct scsi_cmnd *srb,struct us_data *us);
drivers/usb/storage/sddr55.c +1 -0
@@ -29,6 +29,7 @@MODULE_DESCRIPTION ("Driver for SanDisk SDDR-55 SmartMedia reader" );MODULE_AUTHOR ("Simon Munton" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );/* * The table of devices
drivers/usb/storage/shuttle_usbat.c +1 -0
@@ -48,6 +48,7 @@MODULE_DESCRIPTION ("Driver for SCM Microsystems (a.k.a. Shuttle) USB-ATAPI cable" );MODULE_AUTHOR ("Daniel Drake <[email protected]>, Robert Baruch <[email protected]>" );MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );/* Supported device types */ #define USBAT_DEV_HP8200 0x01
drivers/usb/storage/uas.c +1 -0
@@ -1219,5 +1219,6 @@ static struct usb_driver uas_driver = {module_usb_driver (uas_driver);MODULE_LICENSE ("GPL" ); +MODULE_IMPORT_NS (USB_STORAGE );MODULE_AUTHOR ("Hans de Goede <[email protected]>, Matthew Wilcox and Sarah Sharp" );
Signature · 1 line
2.23.0.187.g17f5b7556c-goog
Re: [PATCH v5 00/11] Symbol Namespaces
In reply to Matthias Maennich+++ Matthias Maennich [06/09/19 11:32 +0100]:
Quoted 83 lines
As of Linux 5.3-rc7, there are 31207 [1] exported symbols in the kernel. That is a growth of roughly 1000 symbols since 4.17 (30206 [2]). There seems to be some consensus amongst kernel devs that the export surface is too large, and hard to reason about.
Generally, these symbols fall in one of these categories:
1) Symbols actually meant for drivers
2) Symbols that are only exported because functionality is split over multiple modules, yet they really shouldn't be used by modules outside of their own subsystem
3) Symbols really only meant for in-tree useWhen module developers try to upstream their code, it regularly turns out that they are using exported symbols that they really shouldn't be using. This problem is even bigger for drivers that are currently out-of-tree, which may be using many symbols that they shouldn't be using, and that break when those symbols are removed or modified.
This patch allows subsystem maintainers to partition their exported symbols into separate namespaces, and module authors to import such namespaces only when needed.
This allows subsystem maintainers to more easily limit availability of these namespaced symbols to other parts of the kernel. It can also be used to partition the set of exported symbols for documentation purposes; for example, a set of symbols that is really only used for debugging could be in a "
SUBSYSTEM_DEBUG" namespace.I continued the work mainly done by Martijn Coenen.
Changes in v2:
- Rather than adding and evaluating separate sections__knsimport_NS, use modinfo tags to declare the namespaces a module introduces. Adjust modpost and the module loader accordingly.
- Also add support for reading multiple modinfo values for the same tag to allow list-like access to modinfo tags.
- The macros inexport.hhave been cleaned up to avoid redundancy in the macro parameters (ns, nspost, nspost2).
- The introduction of relative references in the ksymtab entries caused a rework of the macros to accommodate that configuration as well.
- Alignment ofkernel_symbolin the ksymtab needed to be fixed to allow growing thekernel_symbolstruct.
- Modpost does now also append the namespace suffix to the symbol entries in Module.symvers.
- The configuration optionMODULE_ALLOW_MISSING_NAMESPACE_IMPORTSallows relaxing the enforcement of properly declared namespace imports at module loading time.
- Symbols can be collectively exported into a namespace by definingDEFAULT_SYMBOL_NAMESPACEin the correspondingMakefile.
- The requirement for a very recent coccinelle spatch has been lifted by simplifying the script.
- nsdeps does now ensuresMODULE_IMPORT_NSstatements are sorted when patching the module source files.
- Some minor bugs have been addressed in nsdeps to allow it to work with modules that have more than one source file.
- The RFC for the usb-storage symbols has been simplified by using DEFAULT_SYMBOL_NAMESPACE=USB_STORAGE rather than explicitly exporting each and every symbol into that new namespace.Changes in v3:
- Reword the documentation for theMODULE_ALLOW_MISSING_NAMESPACE_IMPORTSoption for clarification.
- Fix printed required version of spatch in coccinelle script.
- Adopt kbuild changes for modpost: .mod files are no longer generated in .tmp_versions. Similarely, generate the .ns_deps files in the tree along with the .mod files. Also, nsdeps now uses modules.order as source for the list modules to consider.
- Add an RFC patch to introduce the namespaceWATCHDOG_COREfor symbols exported inwatchdog_core.c.Changes in v4:
-scripts/nsdeps:
- exit on first error
- support out-of-tree builds O=...
-scripts/export_report.pl: update for new Module.symvers format
-scripts/mod/modpost: make the namespace a separate field when exporting to Module.symvers (rather than symbol.NS)
-include/linux/export.h: fixed style nits
-kernel/module.c: ensure namespaces are imported before taking a reference to the owner module
- Documentation: document the Symbol Namespace feature and update references to Module.symvers and EXPORT_SYMBOL*
Quoted 8 lines
Changes in v5:
-Makefile: let 'nsdeps' depend on 'modules' to allow
make clean; make nsdepsto work
-scripts/nsdeps: drop 'exit on first error' again as it just makes more problems than it solves
- drop the watchdog RFC patch for nowThis patch series was developed against v5.3-rc7.
Great work Matthias!
I think this patchset is shaping up nicely. As the merge window is coming up soon, I'd like to queue this up in modules-next by the end of today to allow for some testing and "soak" time in linux-next. If there are any more complaints, please speak up.
Thanks!
Jessica