On Tue, Feb 21, 2006 at 09:24:23PM +0100, Carlos Mart?n wrote:
> > acx-common-y += wlan.o conv.o ioctl.o common.o
> > acx-pci-y += pci.o
> > acx-usb-y += usb.o
> >
> > obj-$(CONFIG_ACX_PCI) += acx-common.o acx-pci.o
> > obj-$(CONFIG_ACX_USB) += acx-common.o acx-usb.o
>
> This is how we had it before, which leads to having a lot of the same code on
> both modules. The unified driver is not much larger so it was made this way,
> and that's where all the problem comes from.
> Wouldn't this lead to duplicated function definitions at link time if both
> are
> compiled-in? From your module split above I understood you wanted acx-common
> to be another module, but here I see it goes into the modules.
>
No. The above makefile fragment builds three modules: acx-common.o,
acx-pci.o and acx-usb.o as mentioned above. The magic here is that with
that makefile fragment is that the kbuild systems builds acx-common.o if
either CONFIG_ACX_PCI or CONFIG_ACX_USB is set, and even makes sure to
do the right thing if either is builtin. There is not code duplication
at all.
> > ---- snip ----
> >
> > - kill the IS_PCI/IS_USB macros and add a acx_operations structure that
> > handles the different hardware without branches all over and allows
> > the hw-specific code to be in separate modules.
>
> There aren't that many IS_{PCI,USB} uses and most if not all are justified
> (extra step for one case). It might be a good idea to do that for the
> IS_ACX{100,111} macros instead of calling the generic function which then
> calls the chip-specific one.
The important bit is that you need the pointers with the above module
spit, because you can't call usb- or pci-specific routines from acx-common.ko
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
