netdev - Re: [RFC] ethtool: Expand ethtool

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: <20080715.152758.193724361.davem@davemloft.net>
Date:	Tue, 15 Jul 2008 15:27:58 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	rick.jones2@...com
Cc:	brandon@...p.org, jgarzik@...ox.com, netdev@...r.kernel.org
Subject: Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits

From: Rick Jones <rick.jones2@...com>
Date: Tue, 15 Jul 2008 14:53:16 -0700

> Brandon Philips wrote:
> > Introduce the speed_hi field to ethtool_cmd, using the reserved space,
> > to expand the speed field to 2^32 Megabits/second.
> > 
> > Making this field expansion now gives us plenty of time to fix up the
> > user-space pieces that use SIOCETHTOOL before hardware faster than 64
> > Gb/s is available.
> > 
> > Signed-off-by: Brandon Philips <bphilips@...e.de>
> > 
> > ---
> >  include/linux/ethtool.h |   17 ++++++++++++++++-
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> > 
> > Index: linux-2.6/include/linux/ethtool.h
> > ===================================================================
> > --- linux-2.6.orig/include/linux/ethtool.h
> > +++ linux-2.6/include/linux/ethtool.h
> > @@ -27,9 +27,24 @@ struct ethtool_cmd {
> >  	__u8	autoneg;	/* Enable or disable autonegotiation */
> >  	__u32	maxtxpkt;	/* Tx pkts before generating tx int */
> >  	__u32	maxrxpkt;	/* Rx pkts before generating rx int */
> > -	__u32	reserved[4];
> > +	__u16	speed_hi;
> > +	__u16	reserved2;
> > +	__u32	reserved[3];
> >  };
> 
> I certainly agree with the concept of preparing for faster NICs.  Are 
> bits in that structure sufficiently precious to go the split route, or 
> would it be cleaner to just grab a contiguous 32 bits from the structure?

That's less space we can use to make similar expansions.

And we have to keep the existing u16 chunk there anyways, because existing
applications are only going to provide that part.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html