> This presents another problem because the if_type member of the if_data > struct is defined as a u_char and so the type I've been assigned isn't > even going to fit.
Riiiiiight. > 3. Track down all the places that this might be used, and make sure they > are also changed to handle a u_int32_t. Gigantic ABI breakage. Hope you have fun upgrading bsd, ifconfig, and other tools through that change. > The only place that I can think of that really might break is SNMP > clients, If you change the offset of all the fields in if_data, and all the macros that access inside it, you'll break a lot more than the snmp tools. because I think that the ifType may appear in the SNMP tree. > This is unfortunate, but there are probably more clients that are > currently interpreting CARP interfaces as "Internal LAN on a bridge per > IEEE 802.1ap" and MBIM as "Gigabit-capable passive optical networks > (G-PON) as per ITU-T G.948". If we want to have standards compliance, we > *should* fix this. Some problems created by IANA cannot be solved. In the coming decade I expect they'll come to realize they've allocated all the numbers in the protocols and services files, and start allocating out-of-range numbers there also. They get into this situation reasons: they hand out numbers for things which don't actually need unique numbers, then don't delete ancient irrelevant things. Should fix? Very debatable.
