RE: [PATCH] ethtool_ops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Fri, Jun 06, 2003 at 01:17:46PM -0700, Feldman, Scott wrote:
> > * On get_gregs, for example, would it make sense to ->get_drvinfo
> >   so you'll know regdump_len and therefore can kmalloc an 
> ethtool_regs
> >   with enough space to pass to ->get_regs?  Keep the kmalloc and
> >   kfree together.  Same for self_test, get_strings, and get_stats.
> >   For get_strings, size = max{n_stats, testinfo_len)*sizeof(u64).
> 
> That would be one possibility, but get_drvinfo is quite 
> heavyweight. I think I'd prefer to not do that unless there's 
> a strong feeling about thing.

I'm pretty sure you want to do this.  The less work done in the drivers,
the better.  See Jeff's response on this as well.
 
> > * Can we get an HAVE_ETHTOOL_OPS defined in netdevice.h to support
> >   backward compat?
> 
> I'm hoping to avoid that by getting compatibility code merged 
> into 2.4.22.

I'm not sure what compatibility code you're referring to.  We need to
target older kernels with the same code base, so a simple
HAVE_ETHTOOL_OPS would make this easy.  I'd really like to move over to
ethtool_ops for e100/e1000/ixgb, but it's problematic if we need to
manage multiple code bases.

-scott
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux