On Wed, 22 Aug 2007, David Young wrote:
> I have lengthened sockaddr_dl so that it can accomodate a FireWire
> address.  That doesn't break any user<->kernel ABI, however, a number
> of people have pointed out to me that it 3rd-party programs may rely on
> sockaddr_dl's size remaining the same.

Could you explain this in more detail?  If no ABIs are affected, then
how could already-compiled third-party programs be affected?  Or if
the third-party programs are recompiled against the new definition
of struct_dl, what could go wrong?  Or are we talking about broken
third-party programs that think they "know" how big a sockaddr_dl is
without having to include any headers?

> I am going to return sockaddr_dl to its historical size, and introduce
> sockaddr_link for the kernel to use.  The address family (sa_family)
> of both sockaddr_dl and sockaddr_link remain the same (AF_LINK).  I am
> also going to introduce macros CSLADDR() and SLADDR() whose function
> is analogous to CLLADDR() and LLADDR().  I will rename all of the
> sockaddr_dl_*() routines in the kernel to sockaddr_link_*().  Please
> let me know if this is going to break your mother's back, make your
> cereal soggy, or stop your WiFi from working.

How will we avoid having to do similar renames in future, say next time
somebody invents a link layer with an even longer address format?

--apb (Alan Barrett)