On Thu, Aug 23, 2007 at 09:33:29AM +0200, Alan Barrett wrote:
> 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?

A third-party program might abuse sockaddr_dl by embedding it into a
wire format and assuming a fixed length.  If you recompile the program on
NetBSD, then it might not be able to speak with a second instance of the
program, if that instance was compiled with a different/older net/if_dl.h.

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

In the kernel, we may extend sockaddr_link at will, because sockaddr_link
is not exported to userland, and the kernel users of sockaddr_link do not
(any longer) assume that it has a fixed length.

In the NetBSD base system, kernel and userland, there is nothing
that assumes an AF_LINK sockaddr of fixed length.  Everything reads
sdl_len(/sa_len) to find out the length of an AF_LINK sockaddr.

A hypothetical 3rd-party program that reads/writes AF_LINK sockaddrs
from/to the kernel, today, and that assumes AF_LINK sockaddrs of fixed
length, has always been broken.  It will remain broken.  However,
a hypothetical 3rd-party program that sends/receives AF_LINK sockaddrs
of fixed length to/from instances of itself will not break, because we
will not change the length of sockaddr_dl.

Does that answer your question?

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24