On Wed, 30 May 2001, Dawson Engler wrote:
> Here are *uninspected* 2.4.5-ac4 results of a checker that warns when a
> non-__init function calls an __init function (suggested by
> [EMAIL PROTECTED]). There seem to be two cases:
>
> 1. The best case: the caller should actually be an __init function
> as well. This is a performance bug since it won't be freed.
>
> 2. The worst case: some random post-initialization routine
> calls an __init routine which can cause the kernel to go into
> hyperspace if the __init routine's code has been deleted.
>
> The current messages do not differentiate between these two cases. If these
> results are generally useful, I can fix up the checker, but as it now stands
> there shouldn't be that many false positives.
>
> Dawson
> MC linux bug database: http://hands.stanford.edu/linux
>
> /u2/engler/mc/oses/linux/2.4.5-ac4/drivers/video/cyber2000fb.c:1548:cyberpro_probe:
>ERROR:INIT: non-init fn 'cyberpro_probe' calling init fn 'fb_find_mode'
[ I'm responding to this one only, woken up by Russell ]
But cyberpro_probe() is marked __devinit, so it's used during driver
initialization only.
And fb_find_mode() is special: it's indeed an __init function, but there's also
a special inline variant in <linux/fb.h>, protected by #ifdef MODULE. So this
doesn't harm.
For clarification, fb_find_mode() finds a suitable video mode in the video mode
database (drivers/video/modedb.c). Since we don't want to waste memory, this
database is __initdata. To make life easier for the driver writers, they
can still use fb_find_mode() through the inline function, which knows only
about 640x480@60 Hz.
I guess the correct fix is to (re)implement __init for modules, then we can
link the whole modedb with every frame buffer device driver module...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
