[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
>> [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
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
Main Index |
Thread Index |