Messages in this thread | | | Date | Sun, 14 Jun 2009 20:27:40 -0500 | From | Mike Christie <> | Subject | Re: -git tree build failure #2: drivers/net/cnic.c:2520: error: implicit declaration of function ‘ symbol get’ |
| |
James Bottomley wrote: > On Sat, 2009-06-13 at 17:43 -0700, Michael Chan wrote: >> On Sat, 2009-06-13 at 13:42 -0700, James Bottomley wrote: >>> On Sat, 2009-06-13 at 13:11 -0700, Linus Torvalds wrote: >>>> >>>> That makes no sense. >>>> >>>> Look at the first #include in the file - it already includes >>>> <linux/module.h>. >>>> >>>> Why do we need to do it twice? >>> We don't ... it's the wrong fix. The actual problem is that >>> __symbol_get() is only defined for the modular case. What it looks to >>> be doing is a reflection call on bnx2_cnic_probe(). I'm not sure why >>> it's doing this ... other than perhaps cnic wants to avoid an explicit >>> bnx2 dependency? I actually think it's incorrect, since the netdev code >>> before it just checked bnx2 is present, so I see no harm in an explicit >>> call, so this should fix it. >>> >>> If it had a good reason for the reflective call, then symbol_get() >>> without the __ should be used. >>> >>> Michael Chan, could you confirm? >>> >> Thanks James and Ingo. We don't want to have a symbol dependency on >> bnx2 because this driver eventually will support the 10G bnx2x driver as >> well. So we want the driver to support either or both NIC drivers >> without both drivers loaded. Please use the patch below. > > Um, but that's not going to work very well. When you have your 10G > driver, they'll both have to export the symbol name bnx2_cnic_probe > which the kernel isn't going to like. You can differentiate the symbols > and add a multiple symbol lookup in init_bnx2_cnic(), but that's getting > ugly. > > What about doing something more standard, like bus matching? That's how > the SCSI upper layer drivers work: we export a virtual SCSI bus and > they bind to it if a supporting device appears. You could do something > similar exporting a virtual cnic bus from your network drivers and get > the cnic driver to bind to it. >
Something like bus matching would be nice. I think this is going to be a bigger problem in the future with everyone putting as many functions on a card as possible. We already have the cxgb3 net driver with a iwarp (iw_cxgb3) and iscsi (cxgb3i) driver, so maybe something in the net or driver model code would be best?
Today, you can't have two pci_drivers attaching to the same device can you?
| |