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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ