RE: crc32 cleanups

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)!