Re: 2.6.17-mm2

[Randy.Dunlap]

On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote:

> On Fri, Jun 30, 2006 at 12:38:13AM -0700, Randy.Dunlap wrote:
> > Until modpost (or whatever) can do this, here are a few that
> > a shell script has found for me by examing source code only --
> > may contain some false reports:
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:81:EXPORT_SYMBOL(at91_set_A_periph)
> > ./arch/arm/mach-at91rm9200/gpio.c:67:int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:101:EXPORT_SYMBOL(at91_set_B_periph);
> > ./arch/arm/mach-at91rm9200/gpio.c:87:int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:122:EXPORT_SYMBOL(at91_set_gpio_input);
> > ./arch/arm/mach-at91rm9200/gpio.c:108:int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:144:EXPORT_SYMBOL(at91_set_gpio_output);
> > ./arch/arm/mach-at91rm9200/gpio.c:129:int __init_or_module at91_set_gpio_output(unsigned pin, int value)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:160:EXPORT_SYMBOL(at91_set_deglitch);
> > ./arch/arm/mach-at91rm9200/gpio.c:150:int __init_or_module at91_set_deglitch(unsigned pin, int is_on)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:177:EXPORT_SYMBOL(at91_set_multi_drive);
> > ./arch/arm/mach-at91rm9200/gpio.c:166:int __init_or_module at91_set_multi_drive(unsigned pin, int is_on)
> >
> > ./arch/arm/plat-omap/mux.c:196:EXPORT_SYMBOL(omap_cfg_reg);
> > ./arch/arm/plat-omap/mux.c:58:int __init_or_module omap_cfg_reg(const unsigned long index)
> > 
> 
> These would appear to be false:
> 
> #ifdef CONFIG_MODULES
> #define __init_or_module
> #define __initdata_or_module
> #else
> #define __init_or_module __init
> #define __initdata_or_module __initdata
> #endif /*CONFIG_MODULES*/
> 
> and:
> 
> #else /* !CONFIG_MODULES... */
> #define EXPORT_SYMBOL(sym)
> #define EXPORT_SYMBOL_GPL(sym)
> #define EXPORT_SYMBOL_GPL_FUTURE(sym)
> #define EXPORT_UNUSED_SYMBOL(sym)
> #define EXPORT_UNUSED_SYMBOL_GPL(sym)
> 
> means that in the modules case, they aren't marked as __init and are
> exported, but in the non-modular case they are marked as __init but
> not exported.
> 
> Hence, export symbols marked as __init_or_module is safe.

Thanks for checking + feedback.

> > ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info);
> > ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info)
> > 
> > ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info);
> > ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info)
> >
> > ./sound/i2c/l3/uda1341.c:929:EXPORT_SYMBOL(snd_chip_uda1341_mixer_new);
> > ./sound/i2c/l3/uda1341.c:769:int __init snd_chip_uda1341_mixer_new(struct snd_card *card, struct l3_client **clntp)
> 
> These are definitely buggy.

Only if we have a policy of not exporting __init or __initdata or
__exit.  Are we there yet??

snd_chip_uda1341_mixer_new() is called from
sound/arm/sa11xx-uda1341.c::sa11xx_uda1341_probe(), which is
__init, so it looks safe to me, although I support a policy
that EXPORTs cannot be __init or __exit or __initdata.

---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/