Re: sin_zero

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [changing the AF_INET routing table config to ignore sin_zero]
>> What I'm wondering is, would this break anything?  It seems to me
>> like a no-downside change, but [ICBW].  I'm of the opinion that the
>> most correct thing to do is to change it and then fix anything it
>> breaks, because that really is the correct configuration.  But [...]

> From theoretical point of view, I agree with you.  However, From the
> practital, I am wondering whether your modification may break
> existing routing daemons such as routed, gated, mrt, zebra (quagga),
> xorp and so on because they listen on a routing socket to import
> kernel routes into them.  At a glance, routed seems to be okay but
> others are unknown.

I have tried the change.  Nothing exploded, but I wasn't running any
routing daemons except my own (which is not a routing daemon in the
sense of zebra or routed; the details aren't really relevant here).  My
code succeeded in its attempts to install routes and suchlike, but the
problem was still present - the new routes did not get used by packets,
nor by `route get'.

Note that I did not change sizeof(struct sockaddr_in) itself to
actually eliminate sin_zero; all I changed was the radix tree
parameters used for AF_INET.

> BTW, even with your modification, you may still need to properly set
> sin_len to not sizeof(struct sockaddr_in) but like offsetof(struct
> sockaddr_in, sin_zero) in order to make kernel ignore uninitialized
> sin_zero.

I tried that; attempts to manipulate the routing table that way
produced errors.  I have a fuzzy memory that there's code that checks
that sa_len is "correct" for sa_family; I didn't have the leisure at
the time to check this theory out in detail.

I'm hoping to dig more tomrrow.  I may, for example, try eliminating
sin_zero from struct sockaddr_in altogether and see what happens.  I
also may dig into the radix tree code more to figure out why the routes
weren't getting used when I changed the config but nothing else.

> I am afraid that this would make it difficult to write a portable
> code because all OSes do not have non-standard sin_zero field.

There is that; if I make my kernel tolerant of non-zero sin_zero, or if
I eliminate sin_zero entirely, then the need to bzero structs
sockaddr_in goes away, leading to code being written that doesn't.

I'm not entirely sure how I feel about that.  There are other cases
where I've made changes and have ended up thinking them worth the
nonportability they bring (AF_TIMER sockets and labeled control
structure come to mind immediately); I don't know which way I'd decide
about this, if/when I get it working.

> Just initializing struct sockaddr_in with all zeros is very
> portabale, IMHO.

Certainly.  Anything that breaks code written that way is, IMO, a bug;
it doesn't affect fields set explicitly, and anything depending on bits
other than the four advertised members I consider broken.  That's why I
want to eliminate the dependency on sin_zero now; I consider the
current behaviour, where things work or fail depending on sin_zero,
broken.  I just propose to render such initialization unnecessary, not
actively harmful, and even that much only in my experimental kernels
for the moment. :-)

/~\ 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