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-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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
