Subject: Re: restoring sockaddr_dl size; introducing sockaddr_link
To: None <email@example.com, firstname.lastname@example.org>
From: Alan Barrett <email@example.com>
Date: 08/23/2007 09:33:29
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)