On Tuesday 21 February 2006 21:32, Christoph Hellwig wrote:
> On Tue, Feb 21, 2006 at 09:24:23PM +0100, Carlos Mart?n wrote:
> > 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.
Then all is good.
>
> > > ---- 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
Yes, I realise that (unless you export them, but I don't think we want that).
I've started this, but I think it'll probably be next week before I have time
to really work on it.
This approach is probably better even if the driver is unified. Pointer
dereferences are cheaper than branches/jumping, aren't they?
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-
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
