Andi Kleen wrote:
> On Thu, Jan 24, 2002 at 06:26:50AM -0800, David S. Miller wrote:
> > From: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
> > Date: Thu, 24 Jan 2002 15:25:39 +0100
> > Jeff Garzik writes:
> > > I don't think this was discussed with DaveM, but since the SNMP MIBs
> > use
> > > 64-bit numbers and newer GigE cards use 64-bit numbers, we pretty much
> > > decided at the kernel meeting that netdev_stats should go to 64-bit.
> > I put my vote there too.
> > I have no problems with it, as long as we don't horribly break tools
> > that parse the values we export now.
> Unfortunately they will very likely. glibc scanf and strtoul() have overflow
> checking and will return ERANGE or stop (*scanf). nettools uses sscanf
> for example.
> The only way I see to do it in a compatible way is to still supply %INT_MAX
> values in the old fields and add new fields for the 64bit values.
> There are also a lot of broken /proc/net/dev parsers around so it may be a
> good idea to use a new /proc/net file and leave the old alone.
Using procfs is lame in the first place, IMHO, and viro will rightly
yell at us for adding new files.
Whatever method we choose, though, I agree that there is not much way
around creating a new method for getting that data.
Maybe drivers could pass a list of 64-bit values to ethtool, along with
a version number. ethtool would then use that version as a key for
decoding which values belong with which names "rx errors", "rx missed
I have very little preference for the interface, besides -not- dumping
yet another random file into procfs...
Jeff Garzik | "I went through my candy like hot oatmeal
Building 1024 | through an internally-buttered weasel."
MandrakeSoft | - goats.com