David S. Miller wrote:
struct ethtool_perm_addr {
unsigned int cmd;
int size;
char data[0];
};
and the user says how large his buffer is in the request,
and if that is not large enough you return -ETOOBIG or
some similarly discernable error code so that userspace
can allocat
On Thu, Jul 28, 2005 at 12:50:20PM -0700, David S. Miller wrote:
> Netlink uses this kind of thing a lot, but not too much ethtool
> stuff does. But something like:
>
> struct ethtool_perm_addr {
>unsigned int cmd;
>int size;
>char data[0];
> };
>
> and the user says how
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Thu, 28 Jul 2005 15:47:02 -0400
> On Thu, Jul 28, 2005 at 12:38:53PM -0700, David S. Miller wrote:
> > Probably it is better to define the ethtool object returned to the
> > user as some kind of TLV, so the size doesn't matter.
>
> Can you point
On Thu, Jul 28, 2005 at 12:38:53PM -0700, David S. Miller wrote:
> From: "John W. Linville" <[EMAIL PROTECTED]>
> Date: Thu, 28 Jul 2005 10:56:20 -0400
>
> > I wonder how many files include ethtool.h w/o including netdevice.h...?
>
> This makes userspace inclusion a pain, in fact I bet adding
> t
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Thu, 28 Jul 2005 10:56:20 -0400
> I wonder how many files include ethtool.h w/o including netdevice.h...?
This makes userspace inclusion a pain, in fact I bet adding
the linux/netdevice.h include will break the build for
somebody.
And what if we
John W. Linville wrote:
> I wonder how many files include ethtool.h w/o including
> netdevice.h...?
>
> Anyway, why not just include netdevice.h at the top of ethtool.h?
> Lots of other header files do it e.g. ethdevice.h, inetdevice.h,
> if_arp.h, if_bridge.h, if_vlan.h, ip.h, neighbour.h, sock.
On Thu, Jul 28, 2005 at 09:42:14AM -0500, Jon Wetzel wrote:
> On Wed, Jul 27, 2005 at 09:56:05PM -0400, John W. Linville wrote:
> > Jon, you should probably add a patch (or redo you current patch)
> > and use MAX_ADDR_LEN instead of adding the new ETH_MAX_ADDR_LEN...
>
> I wanted to do this initi
First off, I think making the get_perm_addr function into an
ethtool op is a fine idea. Also, thanks for catching the
unmatched bracket; once again I have been humbled by the
"errant backspace".
On Wed, Jul 27, 2005 at 09:56:05PM -0400, John W. Linville wrote:
> Drivers would still have the op
On Wed, Jul 27, 2005 at 06:45:18PM -0700, cramerj wrote:
> Stupid question: Can we assume ethtool will only be used for networking
> devices with a 6-byte hardware address?
I presume not...?
> If not, then the driver-specific approach would give the flexibility of
> copying anything up to MAX_A
; Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: RE: [patch 2.6.13-rc3] ethtool: add generic
> ethtool_op_get_perm_addr routine
>
> Stupid question: Can we assume ethtool will only be used for
networking
> devices with a 6-byte hardware address?
>
> If not,
-dozen
-Jeb
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of John W. Linville
> Sent: Wednesday, July 27, 2005 6:15 PM
> To: Jon Wetzel
> Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]
> Subject: [patch 2.6.13-rc3]
Add generic ethtool operation for getting permanenet hardware address.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
This moves and renames the basically generic e1000_get_perm_addr
routine to ethtool_op_get_perm_addr, and causes e1000 to make use of
the new name.
drivers/net/e1000/e10
12 matches
Mail list logo
