linux-kernel - Re: -git tree build failure #2: drivers/net/cnic.c:2520: error: implicit declaration of function ‘__symbol

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4A35A38C.1050606@cs.wisc.edu>
Date:	Sun, 14 Jun 2009 20:27:40 -0500
From:	Mike Christie <michaelc@...wisc.edu>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Michael Chan <mchan@...adcom.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	linux-scsi <linux-scsi@...r.kernel.org>
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/