Re: PATCH: linux-2.4.9/drivers/i2o to new module_{init,exit} interface

["Adam J. Richter" <adam@yggdrasil.com>]

>>  	sti();
>> -#ifdef CONFIG_I2O
>> -	i2o_init();
>> -#endif
>>  #ifdef CONFIG_BLK_DEV_DAC960
>>  	DAC960_Initialize();

>Rejected. The ordering is critical because drivers may have both i2o and
>non i2o interfaces. Also an i2o card may control other pci devices and
>we will need to claim the resources beforehand when we finally support that.

	OK, I can fix this in the ordering of "obj-y += ..."
declarations in linux/Makefile.  (If you really need i2o
initialization to occur earlier than do_initcalls(), then that would
also mean that i2o cannot be a module, right?)

>>  dep_tristate '  I2O Block OSM' CONFIG_I2O_BLOCK $CONFIG_I2O
>> -if [ "$CONFIG_NET" = "y" ]; then
>> +if [ "$CONFIG_NET" != "n" ]; then

>NET cannot be modular

	Oops!  Sorry, I accidentally included part of another
change I was fiddling with.


>> -#ifdef MODULE
>>  	i = core->install(c);
>> -#else
>> -	i = i2o_install_controller(c);
>> -#endif /* MODULE */

>This changes all the module dependancy patterns - yes its right, no its not
>appropriate for a "stable" kernel.

	It changes the dependency pattern to the one that is already
used when i2o is a module, not to a new dependency pattern.

	If you want, I can send you a new patch that changes
linux/Makefile to initialize i2o before just before drivers/block,
thereby reproducing the current initialization order, and, of course,
I'll also remove the CONFIG_NET patch that I accidentally put in
before.  Please let me know.

	In any case thanks for looking at my patch and providing the
feedback.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."