[Mono-dev] System.Net.NetworkInformation.IPv4InterfaceStatistics (sysfs statistics)

Jacob Gladish jacobgladish at yahoo.com
Fri Jul 11 21:31:38 EDT 2008


I noticed that the Linux version of IPv4InterfaceStatistics parses the sysfs entries under the /sys/class/net/<dev>/statistics as a long. 
  long Read (string file)
                {
                        try {
                                return long.Parse (NetworkInterface.ReadLine (linux.iface_path + file));
                        } catch {
                                return 0;
                        }
                }

I think this is fine for 32-bit machines, but on 64-bit machines I think that number is an unsigned 64. That method will start returning zero when it gets bigger than signed 64 and probably stay in that state for quite some time before it rolls over.
I was just browsing through net/core/net-sysfs.c for Linux 2.6.9 and all the numbers under statistics are %ul.
/* Show a given an attribute in the statistics group */
static ssize_t netstat_show(const struct class_device *cd, char *buf,
                            unsigned long offset)
{
        struct net_device *dev = to_net_dev(cd);
        struct net_device_stats *stats;
        ssize_t ret = -EINVAL;
        if (offset > sizeof(struct net_device_stats) ||
            offset % sizeof(unsigned long) != 0)
                WARN_ON(1);
        read_lock(&dev_base_lock);
        if (dev_isalive(dev) && dev->get_stats &&
            (stats = (*dev->get_stats)(dev)))
                ret = sprintf(buf, fmt_ulong,
                              *(unsigned long *)(((u8 *) stats) + offset));
        read_unlock(&dev_base_lock);
        return ret;
}
It looks to me that this should be changed to something like:long Read (string file)
                {
                        try {
                                return (long) ulong.Parse (NetworkInterface.ReadLine (linux.iface_path + file));
                        } catch {
                                return 0;
                        }
                }



      


More information about the Mono-devel-list mailing list