On Saturday, March 26, 2005 4:21 AM, Christoph Hellwig wrote: > I took a quick look an a here's a few comments: > > - I don't think renaming mptscsih.c to mpt_core.c makes sense. > the new name is confusing at best, and keeping the old name allows > to keep SCCS history aswell. That means the new SPI stub > driver should > be called mptspi or something like that.
Ok fine. I was wondering whether I should be providing a patch for all the defconfig files down in the arch branch with CONFIG_FUSION=m , so our new drivers(mptspi and mptfc) would be getting compiled into default configurations? > - please don't link mpt_core.o into both mptfch.ko and > mptscsih.ko but > make it a module of it's own I'm not clear on this request. Do you want me to add the mptscsih.ko module back, with module_init and module_exit functions? Thus when someone is either loading mptspi.ko/mptfc.ko, then they would need to load mptscsih.ko as well as mptbase.ko? Bottom line, three drivers loaded for either FC or SPI. Just wondering whether keeping the naming of mptscsih.ko driver would cause any problems. > - the new driver shoild use module_param, not MODULE_PARM I'll fix it. > - why does the fc driver set ioc->spi_data.mpt_pq_filter? Yes - this appplies to fiber. It was requested by engenio, to prevent seeing a dummy Lun. I probably confused you when I saved this command line options in the spi_data member. Fine, I will save mpt_pq_filter somewhere else. > - no need to forward-declare the module_init/module_exit handlers > Fine - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html