struct if_data and ifmibdata

Harti Brandt hartmut.brandt at
Thu Dec 3 22:02:23 UTC 2009


I'm currently working on the networking MIBs for bsnmpd to implement the 
more recent RFCs (including IPv6 stuff). While doing this I run into 
numerous problems accessing interface information. The two sources of this 
information are $subj, each of which has some problems. The main problem 
is missing flexibility because of ABI issues. I have some ideas how to 
relax this somewhat, but before starting to implement anything I though I 
ask around whether this makes sense.

1. struct if_data.

This is embedded into struct ifnet, so any change in size changes the 
ifnet offsets which is bad once we start keeping the ABI stable in 
-current. Other problems are:

   - hard to find out what version of struct if_data one is retrieving via 
either the if_msghdr routing message or via the interface MIB

   - we've run out of ifi_type (u_char) space. IANAIfType is currently at 
251. Actually some of our private defines in if_types.h already overlap 
IANA assigned types

   - ifi_physical is not used anywhere in the kernel as far as I can see 
and should probably be removed together with the associated ioctls. This 
seems to be replaced long time ago by the if_media stuff.

   - we've run out of if_baudrate space (u_long) on 32-bit architectures 
for 10GBit/s interfaces

   - broadcast packet statistics are missing (they are required by the 
actual IF-MIB)

   - ifi_datalen is rather short (u_char) and restricts structure size to
256 bytes.

So what I would like to do is:

   - add a version field at the beginning and a #define to help user 
programs in working with different versions of this structure

   - add a couple of dozens of bytes at the end to allow extending the 
structure without changing its size

2. struct ifmibdata

   - add a version field here too.

3. struct ifmib_iso_8802_3

   - add a version field here too.

   - add dot3StatsSymbolErrors which are required by the current 

Unfortunately only 4 drivers actually implement the ethernet statistics 
:-( so far

So, does this make any sense?


More information about the freebsd-arch mailing list