Re: sockets APIs extensions for Host Identity Protocol

[Keith Moore <[e-mail]>]

have to agree - simply making the length field bigger would break
compatibility for binary object files.

however, you might probably move the location of the length field, leave
sa_family where it is, put a "must be zero" field in its place, and have
the kernel code distinguish between old and new sockaddr structures by
looking at sa_family.

Keith
>> Just change sa_len, sin_len, sin6_len, sun_len, etc, to short instead
>> of char.  (You may want to rearrange the element order for better
>> packing, but that's not essential, just helpful.)
>>
>>> I think it will raise all sorts of backwards compatibility problems.
>>
>> Only if you expect to recompile only part of the world.  There might be
>> code lurking that "knows" those fields max out at 255, but I'd say it's
>> already broken.
>
> Not all of the applications are open source. This change would break
> binary applications which is not very nice. The change would affect
> all sockets, not just HIP based sockets.
>
>> When (if) it comes to releasing OSes with the new _len fields, it gets
>> a little more interesting, but I'd just version the affected calls and
>> ignore the issue.
>
> I don't think that storing of 1 vs. N locators justifies this kind of
> a backwards incompatibility change. It is also a huge deployment barrier.
>