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] [thread-next>] [day] [month] [year] [list]

Message-Id: <1244988911.4096.23.camel@mulgrave.site>
Date:	Sun, 14 Jun 2009 09:15:11 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Michael Chan <mchan@...adcom.com>
Cc:	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’

On Sat, 2009-06-13 at 19:18 -0700, Michael Chan wrote:
> On Sat, 2009-06-13 at 18:33 -0700, James Bottomley wrote:
> > On Sat, 2009-06-13 at 17:43 -0700, Michael Chan wrote:
[...]
> > > 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.
> 
> Yeah, the plan is to have a bnx2x_cnic_probe() when we add support for
> that.  There will be a separate init_bnx2x_cnic() because the hardware
> interface is not exactly the same.
> 
> > 
> > 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.
> > 
> 
> This will require some additional infra-structure.  We can look into
> this when we support the 10G driver.  Thanks.

So if you're going to redo it for the 10G driver, and without the 10G
driver there really seems no need to have a call by reflection in there,
why not simply do a direct call until the 10G driver is added?  This
will save everyone potential hassle from what is a highly unusual
interface.

James


--
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/