Yet another try...
Changes since last time:
* Do away with modules calling init/cleanup_crc32(). This now happens using
module_init(). This avoids refcounting (though I finally got it right with
assistance) and unnecessary pain associated with knowing exactly when in
each module to call init/cleanup_crc32, how many times, etc.
* Each driver that uses crc32 functions now calls request_module("crc32") in
their init or probe function. This way if crc32.o is a module it gets
loaded and initialized prior to use. If it's static, no harm.
I'm concerned by Keith's comment:
> __initcall entries are executed in the order that they are linked
> into the kernel. The linkage order is controlled by the order that
> Makefiles are processed during kbuild and by line order within each
> Makefile. There is definitely a priority order for __initcall code.
Top-level Makefile has:
SUBDIRS = kernel drivers mm fs net ipc lib
And indeed, drivers and fs get built before lib. Therefore, drivers that
use any of the crc32 functions as part of their probe or module_init will be
broken. So, I've moved lib before drivers, both there and in the link
(where it really matters). Now library __init functions are called after
the file system drivers (which I think is OK, as no file systems, even
initrds, are used before the crc32 functions), and before static drivers are
loaded, which is critical. Any objections?
Patches at:
http://domsch.com/linux/patches/linux-2.4.13-pre6-crc32-lib-20011023.patch
http://domsch.com/linux/patches/linux-2.4.13-pre6-crc32-drivers-20011023.pat
ch
http://domsch.com/linux/patches/linux-2.4.13-pre6-gpt-20011023.patch
http://domsch.com/linux/patches/linux-2.4.13-pre6-efivars-20011023.patch
Feedback welcome. I'm hoping to wrap this up soon... :-)
-- Matt Domsch Sr. Software Engineer Dell Linux Solutions www.dell.com/linux #2 Linux Server provider with 17% in the US and 14% Worldwide (IDC)! #3 Unix provider with 18% in the US (Dataquest)! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 23 2001 - 21:00:41 EST