[PATCH] babel: Add support for dual-stack v4/v6 operation

[Toke Høiland-Jørgensen]

Ondrej Zajicek <santiago at crfreenet.org> writes:

> On Tue, May 30, 2017 at 02:04:00PM +0200, Toke Høiland-Jørgensen wrote:
>> Ondrej Zajicek <santiago at crfreenet.org> writes:
>> 
>> > On Tue, May 30, 2017 at 01:48:10PM +0200, Ondrej Zajicek wrote:
>> >> On Tue, May 30, 2017 at 01:37:56PM +0200, Toke Høiland-Jørgensen wrote:
>> >> > > Also channel_is_active() is called but channel may not even exist?
>> >> > 
>> >> > Ah, proto_configure_channel can leave the channel var entirely unset?
>> >> 
>> >> Yes, it could add/remove/reconfigure the channel, based on whether there
>> >> is or is not the configuration and the old channel.
>> >> 
>> >> > was assuming it was just leaving it in place but inactive. Can I just
>> >> > check for NULL, then?
>> >> 
>> >> Yes, that should be enough, as all channels goes up together with the
>> >> protocol and channel cannot be deconfigured when up (protocol will be
>> >> restarted in that case).
>> >
>> > Well i checked that one more time and it is possible that channel is added
>> > after the protocol is up. So you should check that channel is non-NULL and
>> > in state CS_UP, which is something slightly different than what is checked
>> > by channel_is_active().
>> 
>> Right. In that case, is the overhead of always initialising both FIBs
>> acceptable? If it is, I can just use the presence of the channel in all
>> checks for whether an address family is active or not...
>
> I see no reason not to do conditional initialization of FIBs in
> babel_start(). If a channel appears later, it will stay in CS_DOWN until
> protocol restarts (and FIBs are reinitialized), so you could still just
> use the presence and CS_UP state of channel and do not need to check for
> FIB.

Except that the way I implemented things, I just select select the right
fib based on address family; so I'll have to litter checks through all
of that code just to save a few dozens of bytes of memory... Is that
really worth it?

-Toke