Back about two weeks ago I wrote about sin_zero and its relevance to the radix tree used by AF_INET's routing table.
Sunday, I finally got together the round tuits to try eliminating sin_zero altogether, this reinforced by remarks during the previous thread that not everyone has sin_zero and thus code with suitable portability aspirations won't, or at least shouldn't, use it explicitly. Of course, I don't know whether anyone will care. Consider this a report back to the community on an experiment, if you will. :) Working with 4.0.1, because that's what I have easy to build at the moment, I removed sin_zero from the struct definition in sys/netinet/in.h. Then it took fixing only two other files to get the kernel to build, sys/nfs/nfs_export.c and sys/netinet/raw_ip.c. Then I did a sweep for files which textually contained "sin_zero" and fixed them; this meant gnu/dist/gdb/sim/arm/main.c, gnu/dist/gdb6/sim/arm/main.c, share/man/man4/inet.4, usr.bin/talk/ctl.c, and usr.sbin/nfsd/nfsd.c, and ignoring a few other occurrences (eg, in RFCs quoted in files under dist/). All of these fixes were fairly obvious upon looking at the references. Then upon attempting a build of the world, I found I had to fix sbin/routed/output.c and sbin/routed/table.c, which contained initializers which assume the presence of a compound field after sin_addr. Then the world built. AF_INET doesn't work, and I think I know why. This also explains why it didn't work when I just reconfigured the routing table in inetdomain. ARP processing uses sockaddr_inarp (<netinet/if_inarp.h>) for its routes. This struct is just like standard sockaddr_in except that, in place of sin_zero, it has a second struct in_addr and two 16-bit values, and it actually cares what's there, so for inetdomain's routing table to ignore that data breaks it. Unwarranted chumminess with the implementation at its finest; at the very least this deserves big comments on inetdomain where its routing table is configured, and on struct sockaddr_in explaining why sin_zero has to be there. AF_INET networking seems to work on-subnet anyway, and I'm not sure why, since that uses ARPs too - perhaps it was total coincidence.... I am relieved to finally (think I) understand why sin_zero is as necessary as it appears to be. I still think requiring sin_zero to be zero for most interfaces (bind(), routing socket messages, etc) to work is a bug, or at best a misfeature; I think it should be zeroed upon reception by the kernel from userland rather than letting userland leave trash there. But I feel much better understanding why things broke so mysteriously when I shrank the routing table. I'm now going back to a source tree with sin_zero and will be adding prominent comments to it explaining why sin_zero is necessary. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
