Ondrej Zajicek <santiago@crfreenet.org> writes:

On Tue, May 30, 2017 at 02:04:00PM +0200, Toke Høiland-Jørgensen wrote:

...

Ondrej Zajicek <santiago@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