LinuxLists.cc - -git tree build failure in drivers/net/cnic.c: undefined reference to `ip6_route

[permalink] [raw]

Subject: Re: -git tree build failure in drivers/net/cnic.c: undefined reference to `ip6_route_output'

On Fri, 2009-06-12 at 16:51 -0700, David Miller wrote:
> From: Randy Dunlap <[email protected]>
> Date: Fri, 12 Jun 2009 11:43:48 -0700
>
> > Ingo Molnar wrote:
> >> today's -git fails to build with ipv6 disabled (x86):
> >>
> >> drivers/built-in.o: In function `cnic_get_v6_route':
> >> cnic.c:(.text+0x104c42): undefined reference to `ip6_route_output'
> >>
> >> introduced by this new driver:
> >>
> >> a463696: [SCSI] cnic: Add new Broadcom CNIC driver.
> >
> > I just posted a patch for this to netdev and it was acked by its maintainer.
> > Patch is below.
>
> I was hoping the scsi folks, or Linus directly, would pick this up.

I can, but my first tree's just gone ... the next one won't be going
until nearer the merge window.

> But I can take it in too if it slips through the cracks.

That's fine by me too ... If you had a net tree ready, that would be
great ... if not, I'll add it to the next SCSI tree to go.

James

2009-06-13 00:05:23

by David Miller

[permalink] [raw]

Subject: Re: -git tree build failure in drivers/net/cnic.c: undefined reference to `ip6_route_output'

From: James Bottomley <[email protected]>
Date: Sat, 13 Jun 2009 00:03:13 +0000

> On Fri, 2009-06-12 at 16:51 -0700, David Miller wrote:
>> I was hoping the scsi folks, or Linus directly, would pick this up.
>
> I can, but my first tree's just gone ... the next one won't be going
> until nearer the merge window.
>
>> But I can take it in too if it slips through the cracks.
>
> That's fine by me too ... If you had a net tree ready, that would be
> great ... if not, I'll add it to the next SCSI tree to go.

I intend to make my networking pull request late Saturday, or mid-day
Sunday, PST timezone.

So you're taking it would expedite the fix going in potentially.

2009-06-13 06:29:57

[permalink] [raw]

Subject: -git tree build failure #2: drivers/net/cnic.c:2520: error: implicit declaration of function ‘__symbol_get’

* Randy Dunlap <[email protected]> wrote:

> Ingo Molnar wrote:
> > today's -git fails to build with ipv6 disabled (x86):
> >
> > drivers/built-in.o: In function `cnic_get_v6_route':
> > cnic.c:(.text+0x104c42): undefined reference to `ip6_route_output'
> >
> > introduced by this new driver:
> >
> > a463696: [SCSI] cnic: Add new Broadcom CNIC driver.
>
> I just posted a patch for this to netdev and it was acked by its maintainer.
> Patch is below.

This solves the first build failure but there's still a second build
failure:

drivers/net/cnic.c: In function ‘init_bnx2_cnic’:
drivers/net/cnic.c:2520: error: implicit declaration of function ‘__symbol_get’
drivers/net/cnic.c:2520: warning: assignment makes pointer from integer without a cast
make[1]: *** [drivers/net/cnic.o] Error 1
make: *** [drivers/net/cnic.o] Error 2

This too triggers with the config i sent. The patch below solves it
- but i havent done more testing.

Ingo

Signed-off-by: Ingo Molnar <[email protected]>

diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 8d74037..49135cc 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -25,6 +25,8 @@
#include <linux/delay.h>
#include <linux/ethtool.h>
#include <linux/if_vlan.h>
+#include <linux/module.h>
+
#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
#define BCM_VLAN 1
#endif

2009-06-13 06:43:17

[permalink] [raw]

Subject: Re: -git tree build failure in drivers/net/cnic.c: undefined reference to `ip6_route_output'

* James Bottomley <[email protected]> wrote:

> On Fri, 2009-06-12 at 16:51 -0700, David Miller wrote:
> > From: Randy Dunlap <[email protected]>
> > Date: Fri, 12 Jun 2009 11:43:48 -0700
> >
> > > Ingo Molnar wrote:
> > >> today's -git fails to build with ipv6 disabled (x86):
> > >>
> > >> drivers/built-in.o: In function `cnic_get_v6_route':
> > >> cnic.c:(.text+0x104c42): undefined reference to `ip6_route_output'
> > >>
> > >> introduced by this new driver:
> > >>
> > >> a463696: [SCSI] cnic: Add new Broadcom CNIC driver.
> > >
> > > I just posted a patch for this to netdev and it was acked by its maintainer.
> > > Patch is below.
> >
> > I was hoping the scsi folks, or Linus directly, would pick this up.
>
> I can, but my first tree's just gone ... the next one won't be
> going until nearer the merge window.

The thing is, this driver has been submitted 4 days ago, merged by
you 3 days ago and sent upstream two days ago. It has two build
breakages so far, the first one of which triggered on a pretty
common config too.

If you have time for such speedy integration but then dont have time
to test on common configs and dont have time to follow up on and
fix/merge the (pretty much inevitable) upstream breakages you
introduce and get the fixes to Linus, sending prompt fixes next-day
preferably, out of your usual schedule, it would be a better
solution for you to submit new drivers to the staging tree i think -
which does have the capacity to fix and merge such stuff.

Ingo

2009-06-13 07:03:47

[permalink] [raw]

Subject: Re: -git tree build failure in drivers/net/cnic.c: undefined reference to `ip6_route_output'

Ingo Molnar wrote:

> The thing is, this driver has been submitted 4 days ago, merged by
> you 3 days ago and sent upstream two days ago. It has two build
> breakages so far, the first one of which triggered on a pretty
> common config too.
>

Sorry for all the troubles. The final version was submitted 4 days
ago after many iterations. This is actually the 3rd build error so
far. Hopefully, it's the last one. Thanks everyone.

2009-06-13 14:37:49

[permalink] [raw]

Subject: Re: -git tree build failure in drivers/net/cnic.c: undefined reference to `ip6_route_output'

On Fri, 2009-06-12 at 17:05 -0700, David Miller wrote:
> From: James Bottomley <[email protected]>
> Date: Sat, 13 Jun 2009 00:03:13 +0000
>
> > On Fri, 2009-06-12 at 16:51 -0700, David Miller wrote:
> >> I was hoping the scsi folks, or Linus directly, would pick this up.
> >
> > I can, but my first tree's just gone ... the next one won't be going
> > until nearer the merge window.
> >
> >> But I can take it in too if it slips through the cracks.
> >
> > That's fine by me too ... If you had a net tree ready, that would be
> > great ... if not, I'll add it to the next SCSI tree to go.
>
> I intend to make my networking pull request late Saturday, or mid-day
> Sunday, PST timezone.
>
> So you're taking it would expedite the fix going in potentially

OK, I've added it to my patch queue.

James

2009-06-13 20:12:32

by Linus Torvalds

[permalink] [raw]

Subject: Re: -git tree build failure #2: drivers/net/cnic.c:2520: error: implicit declaration of function ‘__symbol_get’

On Sat, 13 Jun 2009, Ingo Molnar wrote:
>
> > I just posted a patch for this to netdev and it was acked by its maintainer.
> > Patch is below.
>
> This solves the first build failure but there's still a second build
> failure:
>
> drivers/net/cnic.c: In function ‘init_bnx2_cnic’:
> drivers/net/cnic.c:2520: error: implicit declaration of function ‘__symbol_get’
> drivers/net/cnic.c:2520: warning: assignment makes pointer from integer without a cast
> make[1]: *** [drivers/net/cnic.o] Error 1
> make: *** [drivers/net/cnic.o] Error 2
>
> This too triggers with the config i sent. The patch below solves it
> - but i havent done more testing.
>
> Ingo
>
> Signed-off-by: Ingo Molnar <[email protected]>
>
> diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
> index 8d74037..49135cc 100644
> --- a/drivers/net/cnic.c
> +++ b/drivers/net/cnic.c
> @@ -25,6 +25,8 @@
> #include <linux/delay.h>
> #include <linux/ethtool.h>
> #include <linux/if_vlan.h>
> +#include <linux/module.h>
> +

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?

Linus

2009-06-13 20:42:40

[permalink] [raw]

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 13:11 -0700, Linus Torvalds wrote:
>
> On Sat, 13 Jun 2009, Ingo Molnar wrote:
> >
> > > I just posted a patch for this to netdev and it was acked by its maintainer.
> > > Patch is below.
> >
> > This solves the first build failure but there's still a second build
> > failure:
> >
> > drivers/net/cnic.c: In function ‘init_bnx2_cnic’:
> > drivers/net/cnic.c:2520: error: implicit declaration of function ‘__symbol_get’
> > drivers/net/cnic.c:2520: warning: assignment makes pointer from integer without a cast
> > make[1]: *** [drivers/net/cnic.o] Error 1
> > make: *** [drivers/net/cnic.o] Error 2
> >
> > This too triggers with the config i sent. The patch below solves it
> > - but i havent done more testing.
> >
> > Ingo
> >
> > Signed-off-by: Ingo Molnar <[email protected]>
> >
> > diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
> > index 8d74037..49135cc 100644
> > --- a/drivers/net/cnic.c
> > +++ b/drivers/net/cnic.c
> > @@ -25,6 +25,8 @@
> > #include <linux/delay.h>
> > #include <linux/ethtool.h>
> > #include <linux/if_vlan.h>
> > +#include <linux/module.h>
> > +
>
> 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?

James

---

diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index a1ff739..d49b6da 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -7345,4 +7345,6 @@ struct bnx2_rv2p_fw_file {

#define HOST_VIEW_SHMEM_BASE 0x167c00

+struct cnic_eth_dev *bnx2_cnic_probe(struct net_device *dev);
+
#endif
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 44f77eb..3db64ad 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -2520,14 +2520,9 @@ static struct cnic_dev *init_bnx2_cnic(struct net_device *dev)
struct pci_dev *pdev;
struct cnic_dev *cdev;
struct cnic_local *cp;
- struct cnic_eth_dev *ethdev = NULL;
- struct cnic_eth_dev *(*probe)(void *) = NULL;
+ struct cnic_eth_dev *ethdev;

- probe = __symbol_get("bnx2_cnic_probe");
- if (probe) {
- ethdev = (*probe)(dev);
- symbol_put_addr(probe);
- }
+ ethdev = bnx2_cnic_probe(dev);
if (!ethdev)
return NULL;

2009-06-13 21:06:51

[permalink] [raw]

Subject: Re: -git tree build failure #2: drivers/net/cnic.c:2520: error: implicit declarati on of function ‘__symbol_get’

* Ingo Molnar <[email protected]> wrote:

> I still had the window open that had the build failure:
>
> LD sound/pci/snd-es1968.o
> CC fs/btrfs/zlib.o
> drivers/net/cnic.c: In function ‘init_bnx2_cnic’:
> drivers/net/cnic.c:2524: error: implicit declaration of function
> ‘__symbol_get’
> drivers/net/cnic.c:2524: warning: assignment makes pointer from
> integer without a cast
> distcc[22461] ERROR: compile drivers/net/cnic.c on ph/32 failed
> make[2]: *** [drivers/net/cnic.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> CC drivers/ide/trm290.o
> CC drivers/scsi/cxgb3i/cxgb3i_ddp.o
> LD sound/pci/snd-fm801.o
> CC net/sched/sch_drr.o
> CC fs/cifs/xattr.o
> CC drivers/scsi/mpt2sas/mpt2sas_base.o
>
> So it's real - even if the fix is bogus. But it's a different
> config - i'll now try to figure out which one it is and why the
> build fails ...

Yes, the bug is real - the fix is not.

Here is the code:

static struct cnic_dev *init_bnx2_cnic(struct net_device *dev)
{
struct pci_dev *pdev;
struct cnic_dev *cdev;
struct cnic_local *cp;
struct cnic_eth_dev *ethdev = NULL;
struct cnic_eth_dev *(*probe)(void *) = NULL;

probe = __symbol_get("bnx2_cnic_probe");
if (probe) {
ethdev = (*probe)(dev);
symbol_put_addr(probe);
}

and that's a very rare use of __symbol_get(). The problem is that
the cnic driver can be built into the kernel too (!CONFIG_MODULES)
but __symbol_get() is (obviously) a modules-code internal function
really. __symbol_get() is only defined in the CONFIG_MODULES section
of module.h.

Ingo

2009-06-13 21:07:15

[permalink] [raw]

Subject: Re: -git tree build failure #2: drivers/net/cnic.c:2520: error: implicit declarati on of function ‘__symbol_get’

* Linus Torvalds <[email protected]> wrote:

> > --- a/drivers/net/cnic.c
> > +++ b/drivers/net/cnic.c
> > @@ -25,6 +25,8 @@
> > #include <linux/delay.h>
> > #include <linux/ethtool.h>
> > #include <linux/if_vlan.h>
> > +#include <linux/module.h>
> > +
>
> 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?

Hm, indeed ... weird - i pasted that error message from a direct
reproducer and when i added module.h the build failure disappeared.
James - please discard the second patch for now, there's something
fishy here.

I tried to reproduce this second problem with the configs i
saved/sent and failed. I'll now started tests with just Randy's fix.

Ingo

2009-06-13 21:11:37

[permalink] [raw]

Subject: Re: -git tree build failure #2: drivers/net/cnic.c:2520: error: implicit declarati on of function ‘__symbol_get’

* Ingo Molnar <[email protected]> wrote:

> > Why do we need to do it twice?
>
> Hm, indeed ... weird - i pasted that error message from a direct
> reproducer and when i added module.h the build failure
> disappeared. James - please discard the second patch for now,
> there's something fishy here.

I still had the window open that had the build failure:

LD sound/pci/snd-es1968.o
CC fs/btrfs/zlib.o
drivers/net/cnic.c: In function ‘init_bnx2_cnic’:
drivers/net/cnic.c:2524: error: implicit declaration of function
‘__symbol_get’
drivers/net/cnic.c:2524: warning: assignment makes pointer from
integer without a cast
distcc[22461] ERROR: compile drivers/net/cnic.c on ph/32 failed
make[2]: *** [drivers/net/cnic.o] Error 1
make[2]: *** Waiting for unfinished jobs....
CC drivers/ide/trm290.o
CC drivers/scsi/cxgb3i/cxgb3i_ddp.o
LD sound/pci/snd-fm801.o
CC net/sched/sch_drr.o
CC fs/cifs/xattr.o
CC drivers/scsi/mpt2sas/mpt2sas_base.o

So it's real - even if the fix is bogus. But it's a different config
- i'll now try to figure out which one it is and why the build fails
...

Ingo

2009-06-14 00:50:06

[permalink] [raw]

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

cnic: Fix __symbol_get() build error.

Ingo molnar <[email protected]> reported the error when CONFIG_MODULES is
not defined.

Signed-off-by: Michael Chan <[email protected]>

diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index a9e2fd3..4d1515f 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -2519,9 +2519,9 @@ static struct cnic_dev *init_bnx2_cnic(struct net_device *dev)
struct cnic_dev *cdev;
struct cnic_local *cp;
struct cnic_eth_dev *ethdev = NULL;
- struct cnic_eth_dev *(*probe)(void *) = NULL;
+ struct cnic_eth_dev *(*probe)(struct net_device *) = NULL;

- probe = __symbol_get("bnx2_cnic_probe");
+ probe = symbol_get(bnx2_cnic_probe);
if (probe) {
ethdev = (*probe)(dev);
symbol_put_addr(probe);
diff --git a/drivers/net/cnic_if.h b/drivers/net/cnic_if.h
index 0638096..d1bce27 100644
--- a/drivers/net/cnic_if.h
+++ b/drivers/net/cnic_if.h
@@ -296,4 +296,6 @@ extern int cnic_register_driver(int ulp_type, struct cnic_ulp_ops *ulp_ops);

extern int cnic_unregister_driver(int ulp_type);

+extern struct cnic_eth_dev *bnx2_cnic_probe(struct net_device *dev);
+
#endif

2009-06-14 01:33:49

[permalink] [raw]

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

James

2009-06-14 02:25:16

[permalink] [raw]

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 18:33 -0700, 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.

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.

2009-06-14 14:15:34

[permalink] [raw]

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

2009-06-14 14:51:25