[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
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,
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
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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |