Hi,

On 18/10/2019 17:19, Theo de Raadt wrote:
>> 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.

Yeah, I didn't say this would be fun.

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

I'm assuming that within OpenBSD base and ports everything can be fixed.
I mean SNMP clients like monitoring appliances, because these numbers
(maybe, I didn't check) appear on the wire.

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

I can also just say everything is fine and make up another "private"
assignment. If people don't feel the work is worth doing, then I won't
do it.

We have 31 numbers we didn't assign to something yet in if_types.h,
which is probably enough for some years yet.

Thanks,
Iain.

Reply via email to