Subject: Re: restoring sockaddr_dl size; introducing sockaddr_link
To: None <tech-net@NetBSD.org, current-users@NetBSD.org>
From: David Young <firstname.lastname@example.org>
Date: 08/23/2007 16:14:03
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?
David Young OJC Technologies
email@example.com Urbana, IL * (217) 278-3933 ext 24