On Fri, Jun 09, 2000 at 03:03:44PM +0300, Julian Anastasov wrote:
> Yes, using fib_select_addr() is not a problem. Oops,
> sorry, my question was for fib_local_source(), not for
> fib_select_addr() but you understood me. We want to keep
> using inet_addr_type() instead of fib_local_source() in
> arp_solicit(). Only there. And it is not a problem the hosts
> to be involved in same logical network to allow them to
> define any number of additional logical networks as local
> but not in the "local" table. I think, this can't be a
> problem for any user which can add routes in other tables,
> i.e. not only in the "local" table :)
> So, can we just in this case to use inet_addr_type?
> I now see that inet_addr_type() is changed too, to
> use fib_lookup. I forgot about this. Yep, with this change
> we can't do this (to limit the local addresses in
> arp_solicit). I have to wait for the final version of your
> patch :)
Using inet_addr_type() in arp_solicit(), especially the current one looking
into local table only, is wrong from conceptual point of view.
It makes decisions that can't be explained in human terms, only as some
manipulations in C language.
It's better not to call any checking function that to call wrong one.
I'll call fib_select_addr() unconditionally.